Достало!

Уж простите, уважаемые камрады, но реально достало.

1. Достало то, что программы для моделирования схем являются платными.
2. Достало то, что программы для моделирования схем чуть больше чем полностью убоги
3. Достало то, что программы для моделирования схем предоставляют кучу нужных функций, но при этом практически полностью игнорируют некоторые вещи, которые облегчили бы жизнь человеков.

Одним словом, вы поняли.



Плакаться на правительство/жись/дороги/etc мне как то не с руки, надо что то делать — постоянно было так. Потому сей принцип — и сюда. С текущим уровнем развития языков программирования высокого уровня реализация сокращается в разы.

Итак, я действительно псих, и действительно пишу программу для создания, редактирования (моделирования??? кто знает) схем и печатных плат. Пишу ее я на шарпе. Пишу как софт, распространяемый свободно. Почему я думаю, что у меня получится? Во-первых, я накопил достаточный опыт в программировании. Занимаюсь этим уже 5 лет. Во-вторых, я прекрасно понимаю, чего мне, как человеку, которого вынужденно чкнули носом в разработку и проектирование ПП, требуется для счастья. В-третьих — это проект для души, который позволяет отдохнуть от очередного «нахерачить ПО для телеметрии автомобилей».

Если у меня в какой то момент времени пропадет интерес, то я просто выложу исходники куда нить — авось кто подхватит. Работе над проектом я уделяю на данный момент около часа — двух в день, но каждый день и уже почти месяц.

Для чего я пишу этот пост?
Ну, начнем с того, что я надеюсь на помощь в плане формирования требований к программе.
Так же, на мой взгляд, это неплохой стимул переживать минутные слабости вида «да ну его нафик» — вроде как начал рассказывать, значит отвечаешь уже не только перед собой (все мы просто охерительные переговорщики с собственной совестью), но уже перед гораздо большей аудиторией.
Ну, и наконец, может кто то возжелает присоединиться к процессу разработки :)

UPD: меня тут вполне себе оправданно чкнули носом в то, я вроде поорал, что меня что то там не устраивает, а как собрался решать проблемы — не объяснил. Исправляем оплошность:

1. Хочу простой и понятный редактор схем. Тут проще показать, чем рассказать, так как в основе своей все то, что есть сейчас, более менее устраивает. А вот мелочей, которые так и просятся, и облегчат жись (но их никто не делает по причине того, что реализовывать эти мелочи — нафик надо) — целый список уже собрался и постоянно дополняется.

Офф. Нда. Охерительное такое пояснение. Все и ничего толком. Исправляемся :)

2. Хочу общую базу элементов, с поиском в онлайне, с автоматическим обновлением. Задолбало искать херню, которую потом надо еще интегрировать и подключать. Хочу одну кнопку.

3. Хочу каталог типовых примеров. Заколебало перерисовывать даташиты.

4. Хочу прямой доступ в один клик к даташитам.

5. Хочу трассировщик с вкусностями вида подсветки на лету расстояний до дорожек, связок через пат-лист с платой элементов с подсветкой на лету при клике, ну и кучей блек-джека и шлюх.

Ну и еще много чего хочу, но и так написал не на месяц работы.
  • 0
  • 30 января 2013, 17:03
  • dtcDev

Комментарии (516)

RSS свернуть / развернуть
C# — значит windows only
ссылку на github было бы хорошо
+2
Не значит, можно и кроссплатформенно сделать.
0
Если Вы про моно, то ему еще очень далеко до нормального функционирования…
+1
Но все равно можно сделать так, чтобы работало.
0
Нет, товарисч полностью прав. моно — жуткое дерьмище, застывшее в своем состоянии где то на уровне .NET 2.0. Почему шарп — так это потому, что визуализация, в т.ч. и 3D. делается просто и элегантно. Не хочу выпускать продукт в сединах.
0
На Qt не просто и элегантно?
0
Не буду поднимать холивар относительно фреймвоков и языков программирования — это удел специализированных форумов и процесс старый, как гавно мамонта :). Просто данность — не QT
-1
Просто не было бы проблем с кроссплатформенностью.
0
К сожалению, кросплатфоменность не ставилась в разряд приоритетов в разработке.
0
С текущим уровнем развития языков программирования высокого уровня реализация сокращается в разы.
Угу. И со старыми граблями :)
0
Держусь из последних сил :))))) Скажем твердое «нет» холиварам о программировании :)

Просто считаю, что выбор языка программирования и голосования «за и против» — бред сивой кобылы, так как, как и с ОС, есть задача и есть пул языков для ее реализации, дающий оптимальное соотношение «время/качество». Вот и все.
0
Хорошо, пока не будем. Подождём evsi и устроим годный срач, а то я уже три подряд пропустил :)
+1
:) тогда предлагаю назначать время и место :)
0
поздно :)
0
«будьте осторожны в своих желаниях ...» :)
+1
Чёрт, я не хотел :(
У меня уже браузер захлёбывается…
0
Попробуй хром. У него JS быстрый, пока не захлебывается вроде.
0
Да хром у меня. Это глюк какой-то был, переоткрыл вклвдку и всё норм.
Но тред всё равно впечатляет :)
0
Это да) Мультихоливарный тред) Почти как Рыжик у Ломачинского.
0
Выбор языка не важен. Делать надо готовые рабочие библиотеки. А на каком языке они написаны — уже не важно :)
0
Просто считаю, что выбор языка программирования и голосования «за и против» — бред сивой кобылы, так как, как и с ОС
Да, бред, пока это вписывается в ваши условия. А так даже если бы и хотел поучаствовать, то не стану. Ставить винду, что бы поучаствовать в разработке как-то напрягает. Равно как и участвовать в разработке продукта, которым не смогу пользоваться (хотя тема, вне всякого сомнения весьма годная, сам не так давно столкнулся с, мягко говоря, ушибленностью на всю голову интерфейсов у программ моделирования). А так да, выбор, конечно, бред и все такое.
0
Прошу простить великодушно :)
0
Просто этим решением вы отсекли от помощи в разработке целый ряд гиков, которые реально могли бы помочь, если проект заинтересует. Кодом, дизайном, библиотеками и т.д. Сделать билд под windows, изначально заточив проект на кроссплатформенность, дело пяти минут.
+1
Я себя к гикам не отношу и не уверен, что смог бы поучаствовать в разработке в силу катастрофической нехватки времени. Но я мог бы предложить решение для базы компонентов, поскольку это непосредственно пересекается с тем, в чем я хорошо разбираюсь. Но как его реализовать на дотнете я ума не приложу, надо написать уйму всего, что давно есть готовое и проверенное под промышленной нагрузкой но не под дотнет. Так что желаю автору удачи.
0
На текущий момент пишу парсеры для свободно лежащих в сети библиотек для всяких кадов. На импорт 5 тысяч позиций ушло два вечера, с разработкой, тестированием и отладкой.
0
Я имел в виду хранение этих данных. Если действительно интересно — велкам в личку.
0
Вот лично мне быстрее вести разработку на .NET, с возможностью в дальнейшем, может быть, портировать алгоритмы под что либо другое. Шарп быстрее в разработке, чем плюса — надеюсь тут Вы не будете спорить? :) А учитывая, что я уже мес. ковыряюсь один, то скорость разработки мне важна как никогда.
0
Я плюсы предлагать и не собирался. Вместо этого я хотел предложить жабу.
0
С шарпа на жабу перевести код — дело вообще нескольких минут. А если Вы предложите достойный аналог xaml, с такой же функциональностью, то завтра же начинаю подготовку к свадьбе :)
0
С гуйней я знаком слабо, так что ничего не подскажу.
0
С шарпа на жабу перевести код — дело вообще нескольких минут.

А Вы оптимист. Теоретически конечно это сделать можно, но это ни как не «дело вообще нескольких минут».
0
Нисколько. Синтаксис аналогичен, и, если абстрагироваться от интерфейса, все остальное переносится достаточно быстро.
0
Есть еще штатная библиотека классов, на которую есть завязки и от которой избавиться довольно сложно.
0
А если Вы предложите достойный аналог xaml, с такой же функциональностью, то завтра же начинаю подготовку к свадьбе :)

Вы можете использовать xaml для java, например через eFace. Но там не все так гладко.
0
Вот-вот
0
Да, как вариант. Правда не знаю, как у неё с визуализацией.
0
Я смотрел. Если использовать натив без тулкитов сторонних — редкостное уныние на уровне WinForms, что автоматом означает постучись головой об стену чтобы сделать красиво
0
Имеет смысл колупать не голый тулкит, а платформу. Скажем, Eclipse RCP или Netbeans Platform.
0
Как раз успел в разгар холливара :)
Если всё действительно так серьезно и обширно собрались разрабатывать, почему бы не вывести данные в один слой абстракции, представления во второй, а алгоритмы в третий, такой себе MVC, только на десктопе
и писать данные например на Protocol Buffers, компилить и генерить для C# вернее для чего угодно. Если проект опенсорсный то и портировать на Java не составит огромного труда
и поддерживаю реквест на ссылку на github
0
Дык на таком принципе все и строится. Отдельно — слой моделей, отдельно — загрузка, отдельно — хранилище, отдельно — БЛ, отдельно — представление.
0
Это решаемый вопрос. На выбор два варианта — Swing и SWT.
0
Вот посмотрите. Это заняло у меня 40 минут, с разработкой гуев, анимашками блинкера, написанием API для установки значения через интерфейс, а так же генерацией на лету анимации для плавного перемещения стрелки (это не для этого проекта, так что не ломайте голову, куда я это впихну :))) Контрол не содержит ни единой картинки. Кто не верит — готов продемонстрировать с расшариванием экрана в скупе создание с нуля.

Так вот. Где еще можно получить такую же скорость разработки интерактивного интерфейса?

0
В программах подобных той, которую вы пишете, гуй занимает совсем не так много. Основное — функционал и тесты к нему. Так что даже если на создание гуя уйдет не час, а пять, это существенно не отразится на скорости написания.
0
Кстати, если речь о моделировании, там нехилый математический скилл прокачивать придётся.
0
Пффф. Вы таки утянули меня в холивар про языки программирования :))))

Во-первых, графики там дохера, как ни крутите. Нагенерить картинок для каждого элемента и оперировать ими — берду подобно, следовательно, графику создаем на лету (даже если брать схему и печатку).

Во-вторых, тут +4, там +5, здесь +10. Итого? Не забываете — час-два в день? За это время (к примеру — сегодня) я сделаю контрол отображения smd + выводных компонентов на печатной плате, который будет автоматически себя строить в соответствии с моделью данных. А что я успею за то же время на Java?
0
Пффф. Вы таки утянули меня в холивар про языки программирования :))))
Ну так навык не пропьешь :)
Во-вторых, тут +4, там +5, здесь +10. Итого? Не забываете — час-два в день? За это время (к примеру — сегодня) я сделаю контрол отображения smd + выводных компонентов на печатной плате, который будет автоматически себя строить в соответствии с моделью данных. А что я успею за то же время на Java?
Производительность это больше вопрос привычки, поскольку инструменты функционально сравнимы. Не идентичны, но сравнимы. Помнится IDEA имела в комплекте гуевую рисовалку для гуя. У еклипса ее не было. Прошло время, у еклипса рисовалки все так же нет, а в идее ее ни для чего серьезного не используют. Потому что оказалось, что руками все равно быстрее получается, к тому же код проще читать, сопровождать и тестировать.
0
ок, давайте :)

xaml — поддерживание множественной вложенности объектов интерфейса, нативная поддержка 3D (псевдо 3D — вообще как два пальца). Поддерживание ресурсных стилей. Простота применения анимации. Большой функционал по визуализации интерфейса посредством стандартных объектов (т.е., по сути, отрисовываем графику в 3 строчки code behind)

.NET:
Binding, ObservableCollections, Linq, EF. Ну и самый великолепный редактор всех времен и народов, который за тобой разве что жопу не подтирает.

Противопоставим всему этому:…?
0
самый великолепный редактор всех времен и народов, который за тобой разве что жопу не подтирает.
Какая у вас VS стоит? ИМХО, вы переоцениваете :), долгое время я тоже так считал, но потом узнал что есть другие редакторы с кучей плюшек :). Ну разве что intellisense в VS реально крут :)
0
VS 10 / VS 12 (хотя от последней не в восторге). Соответственно, обе Ultimate. И что не говорите, но тот набор инструментов, который есть в VS, даст любому из редакторов 100 очков форы
0
Набор системных инструментов, возможно, хотя 60%+ простаивают большую часть времени — а вот сделать набор текста более приятным могли бы. У меня 08, и там, к примеру, нет такой простой вещи, как заключить выделенный код в соответствующий блок по нажатию кавычки или скобки — просто заменяется содержимое выделения на кавычку, к примеру. Не удобные горячие клавиши, почти все двухуровневые, не работают стандартные для многих IDE сочетания вроде ctrl + / для обрамления выделенных строк в комментарий. Там нет кучи плюшек именно для удобного набора кода. Ну а насчет того что инструментарий богат, это да. И лучшего дебагера чем в VS я нигде ещё не видел.
0
Извиняюсь, я вам соврал — у меня 10ка Ultimate стоит, просто забыл что с 8ки перешел уже :)
0
В десятке, кстати, все еще веселей стало, хотя она и перешла в разряд тормознутого монстрика
0
Да, согласен, есть нюансы. Но подсветка синтаксиса, дебагер, трассировка, инструменты тестирования покрытия кода, инструментарий счетчиков производительности… Короче, Вы меня поняли :)))
0
Это, как бы, стандартная функциональность у любой приличной IDE. Кстати, под шарп или дот-нет есть что-то похожее на мевен?
0
Не в курсе, гуй от меня далек. Или я от него. Но вот то, что касается бэкэнда я могу что-нибудь полезное рассказать.
0
Эх, знали бы вы, на сколько заблуждаетесь…
0
В плане?
0
Ответ был плупу, на его «гуй это второстепенное».
0
Я такого не говорил, это был ответ evsi :)
0
Я выше писал, если нативно — на Qt. Библиотеки настолько обширны, что на плюсах только логика описывается.
Конкретно по скорости разработки гуёв не скажу, дальше кнопок дело не заходило, но судя по демкам это укладывается в ваши сроки :)
0
Где еще можно получить такую же скорость разработки интерактивного интерфейса?
JavaFX 2
0
JavaFX 2

спасибо, заинтересовало
0
— демо: www.oracle.com/technetwork/java/javafx/samples/index.html
— преимущество перед C# — реальная WORA (Win/Lin/Mac, скоро обещают Android);
— код на Scala лаконичный как на Python/Ruby code.google.com/p/scalafx/;
— встроенное скриптование на JS/Python/Ruby/Groovy без уродских интерфейсов как в Qt (то, чего реально не хватает например в KiCAD — быстро рисовать свои символы/футпринты/рамки/размножать блоки и т.д.) www.drdobbs.com/jvm/jsr-223-scripting-for-the-java-platform/215801163
0
Спасибо за ссылку

Python/Ruby
А вот это — сомнительное сравнение :)))))
0
почему? уж не с Перлом/Пыхпыхом какими-нибудь сравнивать?
0
Перл — согласен, это вообще что то с чем то. Пых-пых, хоть и популярен, но имеет очень много ловушек, которые приводят к возможностям создать скрытый баг.

Ну а эти два языка не являются, на мой взгляд, образцом идеального языка, коль к кому либо вообще применять этот термин. Лаконичность — еще согласен, но в остальном все не так радужно.
0
поясните
0
1) Уёбищное говно.
2) занимает кучу места.
3) такая графика слишком сложна для отрисовки в RT
4) а что такое А/ч ???
0
3) такая графика слишком сложна для отрисовки в RT
Оно же аппаратно ускоряется, так что пофигу.
А пункты 1 и 2 сильно зависят от применения. В некоторых случаях такие контролы нужны из соображений стиля или наглядности.
0
Зря. Сильно зря.
0
Желательно делать с использованием WPF.
0
на нем и пишу
0
Mono вполне нормально функционирует.
0
Да, только поддерживает функциональность второго фреймвока, что есть древность несусветная
0
:) не совсем правда, местами его подтянули к .NET 4.0 — хотя в плане UI, действительно всё очень печально
0
это если говорить о версии приближенной к .NET 2.0 и базовым классам
Тут людей беспокоит представление приложения, условно говоря GUI, для которого используется WPF, который в mono отсутствует как таковой. Потому если разделить на логику, данные и UI, то можно и на mono запустить если прикрутить свой нативный UI
0
Согласен на все сто. Смысл .NET без WPF? Вся то красота в скорости разработки и обработки гуев, а так — любой ООП язык, та же ява, к примеру.
0
Вы пожалуй не поверите, но есть жизнь на .NET без WPF :) даже для гуёв, с быстрой разработкой и отрисовкой. только о таком как-то страшно аж рассказывать :)
0
Да я то не спорю. Я когда начинал, WPF и в помине не было. Просто зачем костомить то, что делается просто и быстро?
0
да никто вам по этому поводу ничего не говорит, у всех просто вопрос стоял кроссплатформенности, но при грамотной архитектуре проекта, его портируемость — не сложная задача, и если считать, что портировать нужно только GUI, то вполне выполнимая, за разумное время и вменяемые трудозатраты
0
Вот тут полностью согласен. И смысл тогда холиварить? плюса, ява — вопрос только в гуях, которые требуется подтянуть под конкретную платформу. Логика переписывается быстро и просто.
0
kickad, eagle, qucs, geda — чем не устраивают?
помог бы лучше кукс на qt4/5 портировать
+1
Чем не устраивают — см. выше. Одни убоги, другие управляются через жопу. Скажете — ну и что? А суть в том, что пересев после компаса на Solid Works, я понял, ЧТО такое нормальный интерфейс.

Что касается портирования — я дела. этот проект в виде Coding for fun, а потому тема работы решает тут играющую роль.
0
Без обид, но почему вы считаете, что ваш проект будет лучше других и тем более сможет тягаться с монстрами вроде солидворуса, над которыми трудится не один десяток человек? Функционально названные мной программы позволяют делать большую часть работы домашнего хоббиста. Для промышленной работы можно и на платное раскошелиться. Интерфейс кривой, да. Но вы-то сами являетесь специалистом по юзабилити и дизайну интерфейсов? Если да — еще раз говорю, лучше помогите уже развитых проектам, чем распылить силы на еще одно ненужное поделие. Если нет, пост ваш ни о чем. «Все дураки, ничо не умеют, а я вот щас как возьму и все сумею»
0
Никаких обид — все по делу.

В том то и дело, что не хватает. Вот лично мне — не хватает. И не удобно. И головой постучаться. И в маны лазить по 100 раз на пяток действий. И… Ну вы поняли.

Если да — еще раз говорю, лучше помогите уже развитых проектам, чем распылить силы на еще одно ненужное поделие

Это Ваше мнение. Мое — противоположное. Т.е. если Вам не надо, то это не значит, что не надо другим. Что касается участия в другом проекте — еще раз повторю — я хочу получать от работы удовольствие, потому тема та, которая мне нравится. «Лучше сделать то-то» — я это и в основной работе и слышу постоянно, и сам говорю.
0
>>Это Ваше мнение. Мое — противоположное
Это не мое мнение, это опыт. Дело в том, что я не понаслышке знаком с миром свободного ПО. Такие инициативы всплывают не по одному десятку в день. Но очень мало людей доводит их до какого-либо разумного завершения. А потом забрасывает проекты, т.к. интерес, который ими движет, угасает. И остается еще одна нефункциональная, не поддерживаемая, не развивающаяся программа. Хорошо, если документацию хотя бы оставили.
Ваше стремление похвально и я надеюсь, что с вами подобное не случится, однако вложить свои силы в развитие существующего проекта вместо того, чтобы начинать все с нуля, дает гораздо больший шанс того, что ваши усилия не пропадут даром.
Но итоговый выбор, разумеется, за вами
+1
Для моделирования есть LTspice, для рисования и разводки DesignSpark. Из первого можно импортировать во второй. И забыть об Игле, как о страшном сне.
0
Ага, видел. Свят-свят-свят
0
Фичу можно прямо здесь заказать? Онлайновый репозиторий компонентов. Модерируемый и пополняемый хоть через сайт, хоть через саму среду.
0
  • avatar
  • meps
  • 30 января 2013, 17:56
Во, пасибо большое! Прямо не в бровь, а в глаз!

На текущий момент я разделил реализацию компонентов и корпусов на две отдельных подсистемы. Каждая из них синхронизируется при каждом запуске с архивом на стороне сервера. Только у меня под вопросом процесс синхронизации — либо без участия пользователя (что чревато огромными файлами на стороне пользователя, но при этом программа становится менее зависима от интернет соединения), либо — подгрузка данных по поиску, что предъявляет меньшие требования к ширине канала/времени на синхронизацию, но делает пользователя более зависимым от интернета.

Пока в раздумьях…
0
По части юзабилити все уже продумано при установке приложений в никсах — для новенького нужно явно его выбрать и поставить со всеми зависимостями, а для уже установленного периодически сравниваются версии и предлагается обновление. Ну и с удалением тоже просто — стал пакет не нужен, можно просто его удалить, прямо стереть файл или через интерфейс. Качать и апдейтиться по одной деталюшке мне кажется контрпродуктивным.
0
Нет, видимо я криво объяснил. Базы будут весить неслабо, не говоря уже о потребляемых ресурсах. Тут напрашивается решение загружать данные по запросу. Например, резисторы/конденсаторы — must be, равно как и транзисторы. А вот специализированные вещи, такие как GSM модемы, кому то нужны, а кому то нафик не сдались. И в таком случае имеет смысл по запросу обратиться на сервер и при получении данных сохранить их на стороне клиента в библиотеке. Таким образом, решается проблема работы в off line, так как не требуется каждый раз грузить библиотеки, а так же решается вопрос с размером файлов — у нас локально только то, что нужно в текущий момент.
0
Так оно в *никсах и работает.
Базовые детали сразу в комплекте, а модули — по запросу. Плюс «зависимости» один-ко-многим в виде пакетов корпусов; стандартные идут в комплекте, а специфичные — по запросу.
0
Правильно я вас понял — на клиенте мы имеем индекс всего, плюс какую-то часть данных реальных, из категории mast have, а остальное получаем on demand?
Как я понял вы структурировали данные на представление/логику работы (имхо, правильный подход) — загружаться они будут отдельно? Ведь, по сути, имеем частое использование представлений(корпусов, грубо говоря) разными компонентами
0
Да, конечно. Так как я отошел от «куча файликов с одним, блять, компонентиком», то смысла раскидывать на набор библиотек корпуса не вижу. Соответственно, есть обязательный набор, и есть подгружаемый. Корпуса, условные обозначения и зависимости хранятся на диске и подгружаются при старте программы, откуда потом используются всей программой.
0
Обычно, те кто пишут такой отзыв о ПО, просто не смогли разобраться с ним.
Так как большинство программ пишется забугорными компаниями, то софт написан по их стандартам и для их специалистов. Для радиолюбителей этот софт чаще всего не потянет, зачем то, зачем это. Им не приходится решать задача, с которыми сталкивается разработчик ASUS или Samsung. Сам часто не понимаю, что это за фигня и зачем, но когда подрастает уровень оказывается очень нужный функционал.
Если хотите разрабатывать ПО определитесь для кого оно предназначено и будет ли востребовано. Или вам нравится делать бесполезную работу? После этого ответить на вопросы, что должна делать программа будет проще.
Если хотите делать бесплатную программу заводите репозитарий на гитхабе и начинайте вести блог. Так вы имеете шанс обрести своих пользователей, соратников и тех кто вам будет говорить гадости. Они тоже нужны.
P.S. Я всё таки предпочту «купить» на торрентах профессиональный продукт.
+1
  • avatar
  • Wic
  • 30 января 2013, 18:03
Ваше право, полностью согласен.

Поймите — я не делаю «убийцу PCAD». Как правило, начинания, направленные на то, чтобы соперничать с кем то — обречены на провал. Зачем делать что то, что уже сделано, и заранее ставить себя в роль догоняющего? Я делаю то, что нужно МНЕ. И уверен, что у меня получится, равно как и найдет свои отклики у других, которым от софта надо то же, что и мне.
0
Ну что ж — вполне достойный мотив. Почему бы и нет? Много хороших продуктов/проектов начинались «для себя».
Вот только одно но…

Обычно, если людей не пугает критика и чужое участие — проект открывают изначально. Максимально публично.
Не всем так комфортно работать, это тоже нормально, мы все разные. И есть те, кто работает непублично.

Обычно в таких случаях, по поводу «непубличных» проектов (в которых изначально никто другой не участвует) делают такие громкие заявки только тогда, когда есть уже что показать.

Заявление, типа: «Ребята, мир несовершенен, всё плохо, но у меня есть ИДЕЯ. Ждите!» — оно как-то не слишком серьёзно. Реакция на это как правило: «О, чувак… Ну идея… Ну есть… Ну пусть покажет что ли… А… Нечего ещё?.. Ну ладно..»

Но я желаю Вам удачи! пусть получится.
0
Дык извините — я же не против того, чтобы кто то присоединялся к разработке. О чем и писал в заголовке
0
так публикуйте URL репозитория, смелее…
0
Извините, напомнило:
0
  • avatar
  • amx
  • 30 января 2013, 18:04
Ага, примерно так и начиналось :))) вопрос чем закончится
0
Такие топики лучше создавать когда уже есть, что показать. А то желание может пройти и процесс так и остановится на «С текущим уровнем развития языков программирования высокого уровня реализация сокращается в разы.».

зы. Существует замечательная программка Actrix. В ней рисовать что угодно — одно удовольствие, включая схемки. Всякие кады и рядом не валялись. Жаль, что разработчики автокада её выкупили и угробили (когда не удалось превзойти честным путём).
+2
Я понимаю Ваш скепсис. Но. думаю, что дальнейшими публикациями смогу доказать, что это не очередное «айда писать свою ММО»
0
До сих по являюсь тестером для программы домашнего учета радиодеталей на 1С, благо под Linux есть нативный клиент, так вот. Программист думает как проще, пользователь — как удобнее, причем каждый думает, что именно его вариант лучше. В итоге имеем нечто среднее для всех, как следствие привыкать приходиться конечному пользователю. Если вы думаете, что именно ваш проект будет лучше чем все остальные, то пробовать надо, только вот запала обычно хватает на первый «прыжок» когда начинается работа над ошибками — небольшой проект, как правило, умирает, даже если он нравится многим. Свою аудиторию вы получите, но получить масы очень трудно.
0
Любая среда разработки печатных плат или схем имеет ценность, если в ней большое количество библиотек и очень простое добавление элементов. Diptrace, например, мультиплаформенен и содержит более 100тыс компонентов, добавление новых компонентов или обмен библиотеками не состовляет труда. В данном случае 1000 отверстий можно получить бесплатно — в большинстве случаев этого достаточно для домашних поделок, а если это минипроизводство, то можно и купить так же как и материал. Оно того стоит.
0
очередной велосипед-ододневка.
0
Вы бы сказали, какие именно цели Вы преследуете, чем именно Ваша программа будет отличаться от существующих решений. А то из описания не понятно какие именно фичи Вы хотите реализовать, понятно только, что существующее ПО Вас не устраивает.

В любом случае, желаю удачи в Ваших начинаниях. Хотя, положа руку на сердце, я весьма скептически оцениваю Вашу затею. Слишком большой объем работы как для одного человека, плюс данный софт весьма специфический. Но это сугубо мое ИМХО.
0
Спасибо за тычок носом, поправил пост
0
www.ohloh.net/p/kicad
www.ohloh.net/p/fritzing
www.ohloh.net/p/gEDA
www.ohloh.net/p/pcb
www.ohloh.net/p/qucs

Слишком много строк надо написать, хотя бы 50 000 для 1.0 beta.

Более интереснее если кто бы сделал хорошее и подробное описание архитектуры и составных частей такого проекта (PCB EDA). Скурпулезно описал предлагаемые форматы файлов эл.схемы и лэйаута, описал примитивы, объекты и их свойства и сравнил их с имеющимися форматами. Описаний которых практически нет :) Есть только старый 2000 г. SPECCTRA DSN, какие-то жалкие, старые и недописанные обрывки у KiCAD, у самой старой gEDA вообще нет ничего :) У остальных же — коммерческая тайна, или только за немалое бабло. Ну можно еще поковырять (самому) новые форматы xml у EAGLE. Есть еще некий разрабатывавшийся в конце 90-х формат IDF можно посмотреть для общего развития, но он тоже под копирайтом.

Делов то — всего на 1-2 года для 3-х человек, зато сколько пользы было бы после такого проекта. А уж воплотить его в C#, Qt и т.п. нашлось бы масса людей ответвить от него форки.
0
Может Вы правы. Но, кстати, эта часть работы один черт выполняется в виде парсера. Думаете, меня прет сидеть и заполнять ручками БД по компонентам? :)
0
Если писать со скоростью 1000 строк в день, можно управится за 2 месяца. Но это если есть готовый проект, который просто надо закодировать.
0
и потом ещё пол года дебажить и рефакторить…
0
Нет предела совершенству.

Дебаг упрощается пространством System.Diagnostics.Debug + Unit Tests, а рефракторинг… Как правило, еще на этапе написания становится понятно, что куда надо вынести.
0
Как правило, еще на этапе написания становится понятно, что куда надо вынести.
Ага, это если вы один пишете код, и один контролируете архитектуру всего проекта. И да, когда у вас четкие требования и они не меняются по ходу проекта, тогда да, всё понятно изначально
0
Ну пока что я один, а посему пока такой проблемы не стоит
0
А что касается требований, то есть такое понятие, как итеративная разработка, которая диктует построение системы как стрессоустойчивой к внешним воздействиям. Объем кода раздувается, но изменения проходят проще
0
да в курсе я про итеративный подход, только даже это не спасает при координальной смене требований
0
Ну есть такое понятие, как время жизни софта. И потом — у меня есть четкое понимание того, что должно получиться в конечном итоге
0
1000 строк кода — не такой уж и волшебный показатель. На текущий момент у меня получается порядка 200 строк в час.
0
На текущий момент у меня получается порядка 200 строк в час.

Вы уж меня извините, но показатель «На текущий момент у меня получается порядка 200 строк в час» не говорит ни о чем. Даже люди в состоянии «хронический менеджмент головного мозга» не воспринимают всерьез этот показатель. Данный показатель говорит ровным счетом ни о чем.

Вот я, например, могу набирать текст со скоростью несколько тысяч знаков в минуту. Одна проблема – на выходе полная фигня получается :)
0
Прочтите плиз сообщение, ответом на которое и являлось то, что я написал. Строки кода уже давно не используются ни как оценка трудоемкости, ни как оценка значимости, ни, уж тем более, качества. Прозвучал тезис, что если писать по 1000 строк кода в день, то можно закончить за 2 мес. В опровержение я привожу свою производительность в строках кода. Только как то я не знаю, как усреднить это значение для оценки времени окончания, равно как и вообще — куда эту оценку присобачивать
0
Прочтите плиз сообщение, ответом на которое и являлось то, что я написал.

Я читал исходное сообщение. И, безусловно, я согласен, что кол-во строк кода не является показателем сложности проекта.

Просто Вы так запросто ответили

1000 строк кода — не такой уж и волшебный показатель.

По этому, я решил, что Вы согласны измерять сложность реализации в «количестве строчек». Извиняюсь, если я неправильно понял Ваш комментарий.
0
Значит я криво выразился. Что есть верный признак того, что пора в люлю :)
0
На всякий случай, уточню свою позицию. Например, размер ядра Linux 2.6.32 приблизительно 12 606 910 строк. Это факт, объективный показать размера ПО. Но это абсолютно не значит, что при производительности 200 строк кода в час ядро можно переписать «с нуля» за 63035 часов :)
0
Даже с этой оценкой не соглашусь. Я могу написать:

collection.Add(new CollectionItemModel{id=0, name=«someName», data=«someData»});

то же самое:
CollectionItemModel item = new CollectionItemModel();
item.id=0;
item.name=«SomeName»;
item.data=«SomeData»;
collection.Add(item);

1 и 5 строк соответственно. Результат — один и тот же. Разница — первый рекомендуем с точки зрения построения кода, второй — более читабелен, и, как следствие, более поддерживаем.
0
12606910 строк подтверждают мою мысль о том, что вначале должен быть сделан проект с хорошим описанием структуры/связей/объектов, некоторым НИОКР и разбитый на готовые паттерны проектирования. Что и проделал профессор Таненбаум, написав книжку и приложив к ней готовую иллюстрацию/приложение к книжке в виде Minix. Одного студента торкнуло, и он заговнокодил накодил свой форк в виде Linux. Не было бы книжки/готового хорошо задокументированного проекта Таненбаума — не было бы Linux.
0
вначале должен быть сделан проект с хорошим описанием структуры/связей/объектов, некоторым НИОКР и разбитый на готовые паттерны проектирования
Это лучший способ никогда не увидеть готовую программу.
Не было бы книжки/готового хорошо задокументированного проекта Таненбаума — не было бы Linux.
Линух не миникс. А готовая книжка это, в лучшем случае, надежный источник информации о том, как делать не надо.
+1
50% open source ПО на самом деле «закрыто». Т.е. объемы кода таковы, что просто бесполезно вливатся в команду того же KiCAD-а, например, и прочих других. Поскольку никакой вменяемой документации обычно нет, многое не откомментировано. Просто нет в данном случае вменяемой книжки, прочитав которую можно вливатся в проект. Сидеть и колупатся в сотнях тысяч строк кода в течении недель, что бы хоть что-то понять в говнокоде и уяснить связи в модулях/блоках ПО? Спасибо.

P.S. Говнокод, как бы он правильно не был написан — это не инженерия и не конструирование. Нужна нормальная конструкторская документация «для людей» + хорошая книжка/толстая статья с описанием принципов, технологий, прикидок и расчетов.
0
А теперь представьте себе трудоемкость создания такой книги.
0
Нет, это не трудоемко, но полезно для работы/мозга/для последующего кодинга/для развития в этой специализации. В отличии от:

50 000 строк кода — это не трудоемкость? :-) А точнее — это тупой, очень тяжелый и весьма неприятный труд. И возможно бесполезный, поскольку все будет переделыватся 10/20 раз пока это не надоест и автор окончательно не истощится и погрязнет в горах своего кода. В итоге окажется, что C# — это, вообще, вторично и не самоцель, а цель в другом, но она не достигнута, а мозг уже истощен окончательно.
0
Это предложение несколько напоминает любопытную методологию от Кнута — «литературное программирование». Сам Кнут ей успешно пользуется для создания таких систем, как TeX и METAFONT. ИЧСХ, они довольно стабильны.
0
Если сравнить издания талмуда Кнута разных годов, то видно, как он рос (как на дрожжах) как специалист, ну и сами методы и технологии прогр. росли.

Стоит сравнить издания его талмуда, писавшиеся в 60-х (в СССР изданы в начале 70-х) и более поздние 80-х и 90-х.
0
Стоит заметить, что между 1960-ми и 2000-ми само программирование в корне изменилось. Ну и LP вроде он как раз в 80-х или позже разрабатывал.
0
Про переделку по 10/20 раз и полное истощение мозга — это я «не от фонаря», а по личному опыту, т.к. сказать :-)
0
Ну это типичное следствие сразу нескольких причин — плохое проектирование, собственный профессиональный рост, резко изменяющееся в процессе ТЗ. Насколько я знаю, рекомендуется оставить как есть и делать дальше, а не переделывать уже сделанное. Как говорил Дейкстра, «если ваш вчерашний код не кажется вам требующим переписывания с нуля — вы перестали развиваться», так что если поддаваться желанию все переписать — до конца дело доведено не будет. В этом, конечно, тоже не стоит упираться в крайность — некоторые вещи действительно нужно рефакторить.
0
плохое проектирование
Вотерфолл сосет.
0
Еще б я помнил что конкретно этот термин обозначает.
0
Который из двух?
0
А что, телепатор уже заржавел? ;)
0
0
А-а. Ну просто в этой модели «переписывание с нуля» наиболее наглядно)
0
Говнокод — да, но нормально написанный код — сам по себе документация. Хотя и его надо сопровождать дополнительной документаций.
Ну и кому надо — те вливаются. Навык разобраться в уже написанном — один из ключевых для программиста.
+1
Это тоже крайность. Не уподобляйтесь — код должен иметь документацию, но не мемуары «я родился тогда-то, тогда-то начал программировать, и тут мне в голову бах! пришла идея....»

Хорошо документированный код содержит описание назначения классов, описание назначений методов и полей, а так же комментарии внутри кода к самым зубодробильным методом. Все должно быть кратко и по делу.
0
Хорошо документированный код содержит описание назначения классов, описание назначений методов и полей
Это все можно сгенерировать doxygen'ом. Однако ж, doxy-документация критикуется, и критикуется заслуженно. Не надо документировать то, что очевидно из кода — документация должна содержать информацию на уровень выше, то, что нужно из кода уже выколупывать, плотно роясь в нем и его взаимодействии.
А комментарии — это часть кода. Документацией является, но в той же мере, что и сам код.
0
Хорошо документированный код содержит описание назначения классов, описание назначений методов и полей, а так же комментарии внутри кода к самым зубодробильным методом. Все должно быть кратко и по делу.
У меня в нескольких последних проектах документация есть только в интерфейсах, которые выставляются пользователям бэкэнда. Вместо документации применяется простое правило: если без какой-либо документации другой специалист не может прочитать и понять ваш код, его надо рефакторить. Как следствие, код писанный, скажем, два года назад, легко понимается, сопровождается и расширяется. И да, код всегда абсолютно точно описывает, что именно делает программа. В отличие от комментариев.
+1
Добавлю, что весьма важной составляющей в этом подходе являются юнит-тесты, крайне желательно написанные так, что название теста отражает определенный аспект поведения тестируемого кода, а не бессмысленные «testMethodA».
0
Аналогично. Полностью поддерживаю — комменты только в качестве документации для понимания общего назначения класса, к методам, имеющим нестандартный набор принимаемых параметров, и к зубодробильным конструкциям внутри методов. Остальное — трата времени на написание и поддержание в актуальном состоянии, которая в итоге забрасывается и только вводит в заблуждение.
0
комменты только в качестве документации для понимания общего назначения класса, к методам, имеющим нестандартный набор принимаемых параметров, и к зубодробильным конструкциям внутри методов
Если хочется написать комментарий, как правило это означает, что код надо рефакторить. Одно из очень редких исключений — сложные алгоритмы типа компрессии, причем сильно оптимизированные до полной нечитаемости в угоду производительности. Такой код есть далеко не в каждом проекте и даже там, где есть, составляет мизерную долю процента. Остальное должно быть читаемо без документации.
+1
Одно из очень редких исключений — сложные алгоритмы типа компрессии, причем сильно оптимизированные до полной нечитаемости в угоду производительности.
Ну это и есть «зубодробительные конструкции», как я понимаю.
Ну и против комментариев к интерфейсной части я все же ничего не имею. Хотя возможно ты и прав.
0
Вы не правы. У меня есть код, который оперирует 12 моделями данных, делая при этом кросс-выборки, для формирования универсальной структуры железа и датчиков, которые в итоге соединяются вместе для того, чтобы из присланной от устройства строки получить набор датчиков, визуализирующих в ПО состояние этого устройства. Использование длинных имен переменных, которые полностью описывают ее суть, автоматом означает увеличение нагрузки на канал данных при поллинге обновлений информации. В таком случае проще написать комментарий, чем писать класс клон, в котором поле HDDUID приравнивается к HardwereDeviceUniqueIdentificator
0
А это опять же
сильно оптимизированные до полной нечитаемости в угоду производительности
0
В принципе да, только процесс затрагивает не алгоритм решения, а имена свойств класса
0
Вы не правы.
Опыт показывает, что прав.
Использование длинных имен переменных, которые полностью описывают ее суть, автоматом означает увеличение нагрузки на канал данных при поллинге обновлений информации.
Разделите проблему — удобочитаемость для людей отдельно, а оптимальность отдельно. Практически всегда это можно сделать где-нибудь на стыке, где идет перевод из транспортного формата во внутреннюю доменную модель и наоборот. И да, у меня в проектах модельных объектов часто многие десятки, а то и сотни. Нагрузка на канал тоже существенна. Но это не мешает мне делать удобочитаемые модельные объекты.
0
>код всегда абсолютно точно описывает, что именно делает программа

Особенно двоичный.

P.S. Раньше были, да и сейчас наверное есть люди(взломщики/дебажжеры/проектировщики процов), которые вполне по роду проф.деятельности более-менее почитают двоичный код.
0
Особенно двоичный.
Только его нынче в 99% случаев пишет не человек, так что для человека он не читаем. А так — раньше в нем и программировали.
А так по дизасму зачастую можно вполне неплохо понять, что делает программа. Только медленно это — выпиливаются практически все документирующие свойства исходного кода, а самого кода становится больше.
0
Особенно двоичный.
Если вы пишете в двоичных кодах, то они для вас вполне читаемы.
0
>Навык разобраться в уже написанном — один из ключевых для программиста.

Инженер-конструктор не оперирует понятиями кода на каком-то конкретном языке, а оперирует языком блок-схем/алгоритмов/модулей/объектов и т.п.

Пример, 2 программера — пишут на разных языках(или вкурили разное, но весьма объемное API) и как они будут понимать друг-друга, если по листингам только? Как слепой с глухим?
0
Если пишут на разных языках, им либо надо обговорить и задокументировать интерфейсы, либо приходить к одному языку, иначе никак.
+2
Код — и есть та самая схема, изложенная на стандартизованном и понятном языке. Кроме как на уроках информатики, блок-схемы алгоритмов и иже с ними практически нигде не применяются. Применяется документация более высокого уровня, то, что нельзя вынуть из кода простыми средствами вроде doxygen'а или просто просматривания интерфейсов.
Пример, 2 программера — пишут на разных языках(или вкурили разное, но весьма объемное API) и как они будут понимать друг-друга, если по листингам только? Как слепой с глухим?
Если они работают над настолько разными задачами — им и понимать друг друга не придется. Максимум на каком-то стыке, вроде API. Вот он и документируется.
0
API — это и есть важная часть документации. В open source его часто просто нет (ломы писать/некогда). Но сам API — это просто результат неких более общих умозаключений о самой архитектуре и структуре, паттернах программирования. Обычно, это то, вообще, не описывается во многих open source проектах.

Что-то быстро читать по коду можно, но если это не превышает некого кол-ва строк. После скольки-то тыс (не десятков и сотен тыс.) строк уже возникает явный дискомфорт.
0
API как раз меньше всего нужен для работы над проектом. Его документация нужна для того, кто пользуется библиотекой. Хотя в одном проекте мне вполне хватало самодокументирующегося хедера, описывающего API для компилятора. Для работы над проектом куда важнее такая документация, как описание задач и взаимодействия модулей.
Ну и в нормально структурированном коде найти что-то нужное среди 100к (и более) строк не так сложно. Сложнее отследить взаимодействие — скажем, по какой именно цепочке нужное пинается. Или по какой цепочке принимается и как обрабатывается сетевой пакет. Вот это и нужно документировать. Хотя кое-что я по образу и подобию уже имевшегося вполне успешно писал еще до того, как эти цепочки отследил.
0
В 100K и более легко искать баги — исправил и забыл. Что бы учавствовать в проекте этого не достаточно, если нет вменяемой документации, которую, кстати, тоже еще надо быстро усвоить. Но если ее нет… читать по коду? Бывает, что отсутствие док. или ее хреновое состояние — просто способ своеобразно закрыть свое открытое ПО от не нужных форков, чужих глаз, копи-паста и т.д.
0
Участвовал. Не скажу правда про размер, но думаю 100к там было. А вот доков не было. Да и не особо они нужны, кроме как на архитектуру — ее пришлось выяснять у остальных участников и ковырянием кода.
Так что отсутствие документации — скорее отговорки своей лени или некомпетентности.
0
За деньги, да на окладе, тем более не свое — почему бы не поковырятся виллами в куче навоза. За хорошие деньги можно и дерьмо лопатой покидать.
0
Ну если тебе лень разбираться в проекте, который хочешь дополнить — тебе и собственно дополнять так же лень будет.
И еще, зачем ты отвечаешь сам себе, хоть по контексту больше похоже на ответ мне?
0
Но если ее нет… читать по коду?
Use the source, Luke
0
Инженер-конструктор не оперирует понятиями кода на каком-то конкретном языке, а оперирует языком блок-схем/алгоритмов/модулей/объектов и т.п.
У каждого в голове собственное представление о программе. Человек не думает блок-схемами/алгоритмами/модулями/объектами. Во всяком случае точно далеко не каждый. Все, что вы перечислили это такой же язык межчеловеческого общения, как и речь. Код ровно так же может выполнять эту функцию.
Пример, 2 программера — пишут на разных языках(или вкурили разное, но весьма объемное API) и как они будут понимать друг-друга, если по листингам только? Как слепой с глухим?
По описанию интерфейсов.
+1
Слабо себе представляю двух программеров, которым надо взаимодействовать глубже API, которое, если следовать правилу абстракции, вообще должно иметь один метод СделатьХорошо, и которые при этом работают на разных языках программирования
0
Нужна нормальная конструкторская документация «для людей» + хорошая книжка/толстая статья с описанием принципов, технологий, прикидок и расчетов.
Она устареет через день-месяц-год после начала проекта. И, соответственно, абсолютно бесполезной или даже вредной.
+1
Ничего не устареет.

А дополнения можно вносить. OREILY постоянно выпускает новые редакции книжек, которые пишут авторы ПО или хорошие спецы в нем. Делают большое дело, кстати.

У RTOS uCOS исходной точкой (как и у Minix/Linux) тоже была книжка — постоянно обновляется с выходом новых релизов, кстати. Т.е. по сути — важная часть документации. Тоже самое можно сказать и о русских RTOS OSA и scmRTOS — с ними идут неплохие книжки-описания.
0
Документация для пользователей — несколько иной вопрос, чем документация для разработчиков.
0
Документация для пользователей — несколько иной вопрос, чем документация для разработчиков.

Теже яйца — вид сбоку.

Судя по книжке uCOS, где он сам пишет, что тогда не было никакой инфы по RTOS, он юзал по работе какую-то проприетарную RTOS стоящую бешеных бабок и в том числе за тех.поддержку, которая постоянно тем не менее забивала на его просьбы. И он взялся за это дело сам — писать свою RTOS и сразу и статьи по технологии RTOS, которые быстро выросли в книжку. В ней все досконально разжевано про все компоненты RTOS. Вот с этого букваря и выросли возможно люди из FreeRTOS/OSA/scmRTOS/ChibiOS и прочих.
0
Таки нет. Пользователя не интересует устройство черного ящика — только как он себя ведет и как с ним взаимодействовать. Разработчику напротив, нужно глубоко вникать в поведение.
Да и в твоем примере ты описываешь скорее не документацию, а учебник по написанию RTOS.
0
Это тоже пользователи. Только относящиеся к тех.персоналу. Документация она должна быть 2-х уровневая (даже по госту), если ПО открытое или оставляется для себя или продается новому владельцу, уже отвещающему за сопровождение.
0
Разработчики — не пользователи. Любой разработчик пользуется только одной документацией — содержимым своей памяти. Создавать документацию на код — это тратить 70% времени не на собственно создание программы. При этом обученные оной документацией посторонние разработчики в принципе не дадут потерянные 70% работы. А ввести новичка — куда дешевле потратить 100% времени в течение двух недель на его обучение, чем 70% в течение всей жизни проекта.
Так что тебе дали код — исчерпывающую документацию на продукт и свободу его менять. Этого достаточно.
0
Да разговор то о чем? ТС хочет кодить EDA и не прочь сделать это компанией/опенсорсно. Что кодить, как? Тут про интерфейсы API писали, какие интерфейсы, к чему, между чем? Какова объектная структура внутреннего представления лэйаут-файла, какой формат внешнего файла? И т.д. и т.п. Ему это не надо и ничего этого нет. О чем говорить? О том что технологии M$ (C# и т.п.) в несколько раз сокращают объем кодирования? Кодирования чего?

Я и написал, что вначале надо определится с тем что нужно делать и как, т.е. нужна документация, ТЗ, называйте как хотите. Какого вида документация нужна для начала кодирования я уже написал.
0
Для кодирования документация не нужна. Нужно взять «пользовательские истории» и разбить на задачи. Попробовать реализовать в простейшем виде. Пощупать то, что получилось, уточнить требования и повторить. Иначе говоря использовать agile подход. Для проекта, у которого сформулировать точные требования никто не может (а это именно так), такой подход наиболее близкий к требуемому результат и с минимальным количеством лишнего кода/функицональности.
+1
Для кодирования документация не нужна. Нужно взять «пользовательские истории» и разбить на задачи. Попробовать реализовать в простейшем виде. Пощупать то, что получилось, уточнить требования и повторить.
Если все эти вещи собрать в кучу и изложить письменно — это уже можно назвать документацией.
0
Если все эти вещи собрать в кучу и изложить письменно — это уже можно назвать документацией.
В каком-то смысле. У них есть два важных свойства а) пользовательские истории будут изменяться по мере того, как продукт обретает форму и б) пользовательские истории это как бы направление движения, а не требования к готовому продукту. Не говоря уже о том, что, как минимум на начальных стадиях, пользовательские истории вполне могут противоречить друг другу (что совершенно не допустимо, например, для требований в традиционных методологиях). Но как описание того, как примерно должна вести себя система в целом — да, вполне.
0
Ничего не устареет.
Легко и ненапряжно.
А дополнения можно вносить. OREILY постоянно выпускает новые редакции книжек, которые пишут авторы ПО или хорошие спецы в нем. Делают большое дело, кстати.

У RTOS uCOS исходной точкой (как и у Minix/Linux) тоже была книжка — постоянно обновляется с выходом новых релизов, кстати. Т.е. по сути — важная часть документации. Тоже самое можно сказать и о русских RTOS OSA и scmRTOS — с ними идут неплохие книжки-описания.
Все эти описания и книги практически постоянно отстают от текущих сорсов. И, если подумать, это неизбежно, поскольку они выходят после выхода софта, а за это время появляется новая версия.
0
Ну это уже буквоедство :)
Ну не переделыватся же там все кардинально. Изменения в 5%, ну 10% в новой версии. Основная идеология и основные механизмы же не меняются так резко.
0
Ну это уже буквоедство :)
Скорее реальный взгляд на вещи.
Ну не переделыватся же там все кардинально. Изменения в 5%, ну 10% в новой версии. Основная идеология и основные механизмы же не меняются так резко.
Вы не поверите. Случаи, когда две мейджор версии софта (либы или прикладухи) кардинально различаются архитектурно и, как следствие, в поведении, как бы совершенно не редкость.

По поводу 5% и 10%. На одном из предыдущих проектов архитектура менялась трижды за время существования программы. При этом реюз имеющегося кода был 90-95%. Так что 5-10% это вполне может быть очень и очень много с точки зрения архитектуры.
0
P.S. Говнокод, как бы он правильно не был написан — это не инженерия и не конструирование. Нужна нормальная конструкторская документация «для людей»
Код — это и есть исчерпывающая конструкторская документация. Те, кто пытается накрутить на это еще какую-то КД добром обычно не кончают. Ну, кроме тех, кому нужна абсолютно безбажная программа за любые деньги и время, и то вопрос, насколько это эффективно.
0
Тут не хватает известного мужика с кулаком :)
+2
Код самоценен только для програмера, и даже ему может быть наплевать на его собственный код. Но эта самоценность субъективна и не абсолютна. Кто-то считает что так правильно/красиво, другой считает наоборот, третий считает это говнокодом, для менеджера это вообще ноль — главное человеко-часы и графики выполнения, для хозяина это просто прибыль или убытки, а для юзера нечто, что он видит и пользует только снаружи.

Абсолютно Код самоценен математику — человеку, который кодирует некие абстрактные абсолюты окружающего его universum, создает изначальные алгоритмы и формулы (поразрядная арифметика в столбик, теорема Пифагора, треугольник Паскаля, схема вычисления факториала и т.п.). Кроме того, этот, назовем его КОД, получается уже самоценен сам для себя, как абсолют, существующий сам по себе, вне зависимости от того знают о нем или пока еще нет.
0
Код самоценен только для програмера, и даже ему может быть наплевать на его собственный код.
Я там привел ссылку на очень толковое мнение по этому вопросу. Если в двух словах, то код это и есть дизайн программы. Самый важный и наиболее точно отражающий то, что реально реализовано design artifact.
0
Самый важный и наиболее точно отражающий то, что реально реализовано design artifact.
Кроме того, как говорят математики, необходимый и достаточный.
0
Хороший холивар!

Вот уже не верю в код, он не имеет для меня никакой особой ни design, ни эстетической ценности. Имею я право на такое мнение? Осталось только понимание того, что существуют только общее понятие макро-конструкции и блоков стандартных механизмов и решений, вне зависимости от размера программы. И сам код (фактура и мелкая моторика и микрореализация) здесь ни при чем. Исходя из этого, мне, вообще, не понятно, как какой-то код (который всегда можно заменить на другой, переписать на другом языке и т.д.) может быть превыше всего — превыше общего плана, структуры и самой абстрактной конструкции, того что существует вне зависимости от конкретного кода и в информационном плате более сжато/чище и первичнее.
0
Имею я право на такое мнение?
Вполне. Верят же люди в летающие тарелки и пришельцев. Думаю, вполне можно верить и в то, что код не имеет никакой ценности.
И сам код (фактура и мелкая моторика и микрореализация) здесь ни при чем. Исходя из этого, мне, вообще, не понятно, как какой-то код (который всегда можно заменить на другой, переписать на другом языке и т.д.) может быть превыше всего — превыше общего плана, структуры и самой абстрактной конструкции, того что существует вне зависимости от конкретного кода и в информационном плате более сжато/чище и первичнее.
Вот вы не верите, но, на самом деле, именно код первичен. А общий план он общий план и есть. Вот, скажем, у дома, в котором вы живете, тоже есть план, схемы, чертежи. Но живете вы, все-таки, не в них, а в реальной конструкции, построенной из реальных материалов. И, например, на плане нет кривой трубы в водопроводе и щели между панелями, а в реальном доме они есть. И дует из этой щели совершенно не абстракный, а вполне себе реальный сквозняк.
0
Код — это и есть дизайн (design, а не наше дизайн как оформление) продукта. По коду его можно создать и модифицировать. А по любой другой документации продукт придется заново разрабатывать.
0
КД — это комплект документации, позволяющий воспроизвести продукт. Для электронного продукта это, например, схема, чертежи плат, корпуса, etc. Для программного — это исходный код и все, что необходимо для его сборки (скрипты сборки, etc). Вся остальная документация может присутствовать, но необходимой является только сам программный код.
Ну и как и любая документация, код может быть хорошо читаемый, а может быть и говно (ту же STM хают за через задницу написанные доки на МК, то же самое и с говнокодом).
0
Говнокод, как бы он правильно не был написан — это не инженерия и не конструирование.
Рекомендуется к прочтению: www.developerdotstar.com/mag/articles/reeves_design_main.html
0
Я верю в тебя , верю…
0
  • avatar
  • f1n
  • 31 января 2013, 01:31
А теперь берем и переносим этот срач-топик в свой персональный бложек, иначе я его грохну нахер. Не место ему в «Софте»
0
эм… Это в редактировании делается?
0
Вроде готово
0
Ок
0
1. Хочу простой и понятный редактор схем — DipTrace
2. Хочу общую базу элементов и Space-моделей + УГО от официального производителя по стандартам хотя бы ISO
3. Хочу каталог типовых примеров +1
4. Хочу прямой доступ в один клик к даташитам +1
5. Хочу трассировщик с вкусностями +1
6. Хочу редактор у которого бы вместо списка компонентов, и кучи окон при выборе этого компонента, слева был красивый список УГО в виде дерева (ппц как надо)…
+1
Поддерживаю
+1
Не вижу… )
0
А где можно посмотреть конкретно эти стандарты УГО (Условных Графич.Обозначений). Есть ЕСКД/ГОСТ у нас (видимо самое ясное/упорядоченное и строго описанное), а что у америкосов, европейцев, японцев и какие их САПР-ы/рисовалки сделаны полностью по какому-нибудь стандарту? Сейчас даже не могу осмыслить ясно их стандарты (видимо потому что учился по ЕСКД), сколько видел схем «на бумаге» и в EDA (Electronic Design Automation software) не могу сказать, что все одинаково рисуют.
0
Есть локальные стандарты УГО. Универсализма тут, к сожалению, не получится. В программе я планировал менять на лету настройки УГО из спика (применяем ко всем сразу), потому как если есть элемент, то как его отобразить — уже дело исключительно хозяйское.
0
В том то и дело, что Все должны одинаково рисовать, а вот масштаб насколько мне известно не регламентируется, т.е. у меня на принципиальной схеме могут быть например УГО микросхем выполненных по стандартам ГОСТ (или ISO), но разные по масштабу. Как то так…
0
А какой конкретно #ISO. И кто его придерживается? Какой конкретно стандарт в USA и какой в Европе?
0
хз, какой… Не задавался целью искать, лишь предположил, что у них есть некие стандарты «аналогичные» нашим УГО ГОСТ.
0
0
О-o, thanks!
0
Хочу редактор схем для Android с возможностью экспорта нетлиста.
0
Пожалуй, лучше был бы редактор с возможностью хранить схему в клауде. И аналогичный редактор для десктопа. Так что можно было бы редактировать схему в любом удобном месте и в любое удобное время. Если к нему еще добавить библиотеку элементов там же в клауде (расшаренную между всеми пользователями + локальный кеш для быстрого доступа), то это будет совершенно потрясный инструмент. IMHO, именно в этом направлении имеет смысл развивать редактор схем/плат, а вовсе не в сторону рисования очередного гуя, который будет непривычен пользователям уже сущестующих пакетов.
0
Тогда перебрасывать разработку на Unity3D. Там тебе и андроид, и iOS, и натив под мак, и под вин, и даже под линуха чего то там обещают. Единственное, что смущает — разработка прикладной утилиты на игровом движке :)))))
0
Единственное, что смущает — разработка прикладной утилиты на игровом движке :)))))
Зря смущает, тащемта.
0
Да я вот уже тоже задумался. Минусы — геморой с графикой, там на низком уровне все придется выводит. Плюсы — использование специфических инструментов, например collision detection для обработки тех же пересечений дорожек на платах. Ну и плюс, конечно, полный натив для каждой из платформ. Даже в вебку можно публиковать :))))
0
Я уже писал — гуйня не мое. С остальным могу помочь, если не делом, то, как минимум, поделиться опытом и подробным описанием как работает и чего от него можно ожидать (ну и советом как избежать граблей).
0
если бы могли присоедениться на уровне формирования моделей данных, взаимосвязей — был бы признателен. Визуализация — да, большая часть проекта. Логика — часть не меньшая.
0
Велкам в личку, обсудим подробности.
0
Ну ежели облака, то и базу бы понавороченней, в смысле кроме УГО и патернов еще и документацию, вроде такая идея сейчас у еремекса с их ним дельта дизайном. А для андроида и других мобильный осей достаточно нормального редактора схем и вьювера для платы. Вообще рынок мобильных приложений сейчас активно развивается и подобный продукт мог бы быть очень популярный, ну и прибыльный.
0
Просто смысл распаляться, если есть возможность сделать все в одном месте? Из-за адаптации интерфейса под тач? Не сказал бы, что это прям такая сложная проблема.
0
Да я просто озвучиваю свои мечты, а Вам как разработчику предлагаю посмотреть в какой нибудь гугл плей и маркетплейс и оценить перспективу продаж подобного софта, учитывая тот факт что конкурентов на данный момент нет. Например программка электродроид: цена 2.5 бакса количество закачек 10000+.
0
Наоборот, софт нужно сделать бесплатным и общедоступным для разных платформ. Думаю, разработка даже на рекламе легко отобъется.
+2
С общедоступным — согласен, но 2 — 3 доллара, куда еще доступней — типа бутылки пива в качестве благодарности. А для автора-одиночки, небольшая сумма это дополнительный стимул выделить пару часов своего времени в день и сделать программу еще лучше. Можно сделать дополнительный функционал за деньги или еще чего. Для справки: я не программист и не знаю насколько трудоемкий процесс разработки приложения, но тот-же электродроид я купил, для того что-бы разработчик не забросил свой проект.
0
IMHO, правильная комбинация это бесплатная с рекламой и платная без рекламы. Функционально идентичные.
+1
Иногда это вопрос принципа. А иногда — геморроя. Три бакса не жалко, но чтобы заплатить их нужно гемороиться с выстраиванием цепочки оплаты гуглу.
0
Да, конечно, в таком варианте вполне можно сделать универсальную базу компонентов с возможностью пополнения пользователями в стиле а-ля вики. Тогда ничего не мешает собрать на каждый компонент всю возможную информацию, от УГО в разных стандартах и даташита, до ерраты и примеров использования. Если к этому добавить еще конверсию в форматы различных кадов, то такой проект вполне может жить самостоятельно, даже без рисовалки схем.
+1
Пожалуй, лучше был бы редактор с возможностью хранить схему в клауде.
Этого ещё не хватало. Инет отвалился, сервер упал, автору надоело поддерживать, рейд копирастов/патенторастов/конкурентов, пожар, наводнение и прощай работа. Никогда не понимал все эти клауды и гуглдоки. Впрочем, я, конечно неправ — это ведь "клауд", а не какой-то там говнохостинг, это решит все проблемы.
Если к нему еще добавить библиотеку элементов там же в клауде (расшаренную между всеми пользователями + локальный кеш для быстрого доступа)
Без нормальной модерации это превратится в помойку вроде гуглового аппстора. А если аппрувить только хорошее — будут какие-то там десятки мегабайт, размазанные по всей сети. С точки зрения здравого смысла и нормального человека куда проще и надёжней, чтобы пользователи сабмитили хорошие библиотеки, которые будут проверяться модератором, после чего добавляться в стандартный набор, который поставляется вместе с программкой. Но нет, это не модно — только клауд.
0
а может, +/-1 и по количеству голосов уже судить о годности библы?
с другой стороны, оптимальные библы для печи и ручного монтажа сильно разные.
0
а может, +/-1 и по количеству голосов уже судить о годности библы?
Ни разу не видел, чтобы голосовалка давала полезный результат. Редкое (однако нужное, допустим, мне), но хорошее плюсанёт пара человек, и оно будет валяться среди мусора. Популярное плюсанут все кому не лень, а то, что там всё криво и оформлено не по стандарту сделано никого не будет волновать, ведь «работает же». Без грамотного модератора толпа ничего кроме помойки создать не в состоянии.
0
смотреть на плючики в отфильтрованном? т.е. вот такой относительный рейтинг.
0
*плюсики
0
Плюсики годятся разве что для оценки анекдотов — тут же нужна формальная, объективная система оценки, которую плюсики никогда не заменят.
0
объективная оценка возможна в единственном случае — централизованное модерирование. причем модер дрлжен быть объективно беспристрастен. что в реальном мире не достижимо чуть более чем полностью.
0
Ну, в википедии на труде модераторов всё и держится, иначе через час она превратится в свалку. В школе учеников оценивают учителя (допустим, не совсем беспристрастно, но в целом пропорционально знаниям), а что будет, если ученики начнут сами оценивать друг друга? Не надо думать, что пользователи какого-то там сайта разумнее.
0
ну смотри. допустим, модер паяет поделки руками. соответственно, футпринты под пайку в печи получат (естественным образом) меньшее внимание. обратное тоже верно.
0
Зачем нужен такой модер, который не может просто посмотреть и оценить качество исполнения?
0
это реальная жизнь.
0
а что будет, если ученики начнут сами оценивать друг друга? Не надо думать, что пользователи какого-то там сайта разумнее.
Вы не поверите, но есть школные программы обучения, где ученики даже не друг друга, а сами себя оценивают. И, что характерно, делают это более жестко и беспристрастно, чем делает учитель. Вики примерно на этом же держится. Конечно идиотов везде хватает, но в целом результат определяют не модераторы, а на тех, кто пишет годный материал. И что уже совсем интересно, предложенная вами схема практически ничем не отличается по методикам отбора материала. Другой вопрос, что делать это в онлайне не в пример удобнее, чем принуждением пользователей перегружать базу каждый раз полностью с нуля.
0
Меня тоже удивляет феномен Вики — феномен перехода массы серого количества в некое неплохое, в общем-то, качество, и самое главное бесплатное наполнение. Если бы мне сказали 12 лет назад, что такое может быть — не поверил бы.
0
Главное — чтобы явный вандализм выпиливался.
Если хорошее нужно паре человек — они его и так, без плюсиков найдут. Ты же ищешь не самый проплюсованный компонент, а конкретный. А если он интересен паре человек — то вероятно и выбирать не из чего будет, получишь один результат с полутора плюсами.
0
Никогда не понимал все эти клауды и гуглдоки.
Сочувствую. Вы, судя по профилю, намного моложе меня. Однако уже смело можете себя записывать в старперы.
0
Какой ужос — сейчас побегу разбрасывать файло по всему инету, чтобы не быть старпёром.
0
Какой ужос — сейчас побегу разбрасывать файло по всему инету, чтобы не быть старпёром.
Из сказанного мной такой вывод вовсе не следует. Другой вопрос, что вы традиционно хаете то, чего не понимаете и/или не знаете.
0
Не нужно быть химиком и биологом, чтобы определить говно.
0
Не нужно быть химиком и биологом, чтобы определить говно.
Есть еще такой вариант, что то, что вы чувствуете запах говна и видите вокруг одно говно, исходит вовсе не от предметов, на которые вы смотрите, а от ваших очков заляпаных говном. Судя по вашей реакции на окружающую действительность, такой вариант куда как более вероятен, чем то, что все идут не в ногу, а вы один в ногу.
0
Почему-то только у модных продвинутых разработчиков очки говном не заляпаны.
ну ведь это же так модно! Ява, интрнет… сегодня компьютер на работе установил какие-то обновления потихоньку, а потом требовал перезагрузиться. Причем в ультимативной форме. через каждый 5 минут выбрасывал, что сейчас будет перезагрузка, т. к. она необходима для установки обновлений. Как он меня замучал. ему наплевать, что я работаю. Спрашивается: нормальные люди делают программы сейчас? Я его перезагрузил. Но в конце рабочего дня он не хотел выключаться. Написал установка обновлений, не выключайте компьютер, он выключится сам. Мне уходить надо было, но он настроился похоже на пол-часа. Я его вырубил и все
0
Почему-то только у модных продвинутых разработчиков очки говном не заляпаны.
Неа. Они у подавляющего большинства не заляпаны. Только отдельные люди типа вас считают, что любой прогресс и развитие это дань моде и признак загнивания.
0
Люди вроде меня считают, что прогресс — это развитие и совершенствование, а не всё большее усложнение. Те, кто делают софт какие-то окончательно невменяемые стали. Мало чем отличаются от политиков и законотворцев. Пользователь (который работает, а не читает баш и понемножку пишет в ворде) готов лезть на стенку от тормозов и глюков, а ему объясняют, что он ничего не понимает.
0
совершенствование немыслимо без усложнения. если вы этого не понимаете, мои соболезнования.
0
Совершенствование немыслимо при усложнении.
Простота — обязательное условие надежности. Э. Дейкстра.
Космическая станция может (и должна) быть простой. Твой сраный фонарь для велосипеда, в котором 32-х разрядный контроллер, радиомодуль и ещё куча деталек, которых бы хватило на луну долететь — сложен. При этом космическая станция куда ближе к совершенству, чем эта поделка.
0
уточнение: космическая станция для работы.
для массового посещения — уже совсем другое дело.
0
как пример:
кабак как место наиболее эффективного потребления продукта. стол, стул, жратва (в прямом и переносном смысле) на столе.
так нет, ведь лично ты не идешь в первую попавшуюся забегаловку. хочется глянца, обслуживания и комфорта.
в софте все аналогично.
0
Самолёты и корабли для общего посещения. Простые, но красивые решения. Изменили форму носа корабля — получили большую скорость. Простое, элегантное решение (при этом нельзя сказать, что это далось инженерам с лёгкостью, но тем не менее, это простое решение). Проводка в самолёте, выполненная из алюминия позволяет сэкономить немножко веса и, следовательно, топлива. Быдлокодеры же с каждым днём лепят всё больше фреймворков и одни и те же задачи обрастают всё новыми слоями жыра. Даже простой битовый поток не способны сделать без классов (внутри которых колупание по одному битику и прочая мерзость).
0
ой, как лихо с высокой(низкой) орбиты мы скатились в стратосферу.
0
Больше нечего сказать? И там и здесь трудятся нормальные инженеры. Софтом же (как и политикой) занимаются те, у кого в мозгах дерьмо. Даже процессоры для них отличаются лишь «мощностью» и «количеством фарша». А то, что эти рекламные показатели имеют огромное количество нюансов, до тупой башки не доходит.
0
ну, если нет понимания, чем отличаются полеты в стратосфере и на (даже) низкой орбите…

подскажу: посещаемостью.
0
Какая разница с технической точки зрения? Не зря же авиация и космос объединяются, и обоими отраслями занимаются одни и те же организации. Проблемы и задачи очень похожие.
0
разница в дополнительном оборудовании.
0
Софтом же (как и политикой) занимаются те, у кого в мозгах дерьмо.
Так вы, оказывается, софт пишете… Не знал, не знал…
0
Совершенствование немыслимо при усложнении.
Усложнение бывает разным.

Как вы думаете, какой приемник надежнее, на паре чипов или на паре ламп?
0
На паре чипов можно сделать хуже, чем на паре ламп. Смотря как делать.
0
На паре чипов можно сделать хуже, чем на паре ламп. Смотря как делать.
Это не ответ.
0
Это ответ. Кстати говоря, радио на паре ламп так или иначе починить удалось.
Наверное, многим кинозрителям запомнилась та драматическая сцена в «Красной палатке», когда симпатичный радист Бьяджи обнаружил, что в передатчике сломано сопротивление, и та его бурная радость, когда испорченный резистор им удалось заменить самым обычным графитом из карандаша. Действительно, что-то похожее там произошло.

Передатчик на чипах заглючит (зависнет говнософт или запустится бутлоадер и сотрётся прошивка) — восстановить удастся врядли.
0
Это ответ.
Это не ответ и вы это прекрасно знаете. Как знаете и то, что на паре чипов приемник будет как минимум таким же надежным, а на практике — значительно более надежным. При том, что чипы внутри на несколько порядков сложнее ламп. Те слова, которые вы с таким упорством повторяете, касаются, в первую (и единственную) очередь сложности на уровне человеческого восприятия, а не «вообще». И по мере развития науки и техники сложность «вообще» постоянно растет, а сложность на уровне человеческого восприятия остается на практически неизменном уровне.
+1
А трудность для человеческого восприятия прямо исходит из технической сложности. «Современному» человеку это правда не понять и он старательно пихает в технику свои предрассудки и костыли для «облегчения» восприятия вроде биг эндиана или десятичной системы счисления. Чем он делает объективно сложнее технику, сложность накапливается и потом уже мало кто может разобраться в этом.
0
раньше (угу, те самые совеццкие школьники) было пару десятков корпусов логики. кстати, 99,999% и не пытались выяснить, что у той логики под капотом. и ничего, по готовым схемам во всяких радио, моделистах-конструкторах и юных техниках собирали телики и кАмпутеры.
и сейчас ничего принципиально не изменилось. только в тех «квадратиках на схеме» на порядок увеличилась сложность внутренней структуры плюс добавилась возможность запрограммировать поведение.
0
«Современному» человеку
Любому человеку. Так устроено человеческое сознание, что мы можем одновременно держать в памяти и манипулировать (ака «раздумывать над») 7 +- 2 предметами максимум. И вся история прогресса человечества (а не только для столь ненависного вам «современного» человека) это постоянная работа над поддержкой решаемых задач на этом уровне сложности. А дальше все просто — чем выше уровень абстракций, которыми мы манипулируем в процессе «раздумывания над», тем выше полная сложность решаемых задач. При этом на уровне размышления сложность остается постоянной, в пределах возможности человеческого сознания.
0
Чем он делает объективно сложнее технику, сложность накапливается и потом уже мало кто может разобраться в этом.
Вы можете разбраться в вашей любимой межке или, хотя бы, тиньке, на уровне отдельных транзисторов и топологии? А на уровне процессов происходящих в отдельных транзисторах? А на уровне взаимодействия отдельных частиц?
0
А это требуется? Поскольку межка простая, и верхний уровень-интерфейс будет естественным. Верно и обратное — если в системе 10 слоёв яв и оопов, и пользовательский интерфейс будет запутанным (не говоря уж о тормоглючности).
0
Верно и обратное — если в системе 10 слоёв яв и оопов, и пользовательский интерфейс будет запутанным
Да нифига. Хотя бы потому, что в крупном софте интерфейс вообще проектируется отдельными специалистами.
Ну и ООП — как раз то средство, которое позволяет запихать 200к транзисторов в межку c естественным интерфейсом.
0
А это требуется?
Это наглядная иллюстрация применения абстракции.
Поскольку межка простая, и верхний уровень-интерфейс будет естественным.
На уровне транзисторов она сложная. Даже очень. Но вам кажется, что она простая, поскольку вы оперируете на другом уровне. Теперь представьте, что кто-то в состянии подняться еще выше. Ему говномежка кажется примитивной, а i7 простым.
Верно и обратное — если в системе 10 слоёв яв и оопов, и пользовательский интерфейс будет запутанным (не говоря уж о тормоглючности).
Не порите чушь, ей больно.
0
Простота — обязательное условие надежности. Э. Дейкстра.

Уважаемый Дейкстра прав, но не следуют воспринимать данную цитату настолько буквально.

Пара лошадей, запряженных в четырехколесную повозку – это просто и надежно. Но современные люди не хотят ездить на таких повозках, несмотря на их простоту и надежность. Они хотят автомобиль, при том не абы какой, ВАЗ-2101, несмотря на свою относительную простоту, нынче популярностью не пользуется.

Требования к тому или иному продукту постоянно возрастают (одновременно с общим прогрессом) и чтобы удовлетворять этим требованиям — пригодиться усложнять продукт. Да нужно стремится к простоте, но в рамках разумного, в рамках современных требований.
0
Пара лошадей, запряженных в четырехколесную повозку – это просто и надежно.
Насчет надежно вопрос спорный. Как почитаешь какого-нить Майна Рида, так у них вечно оси ломаются и колеса отваливаются :) Ну и лошади периодически дохнут.
0
Да ладно, оси/колеса можно достаточно просто заменит, главное иметь аварийный ЗИП. А лошади вообще продублированы в режиме автоматического распределения нагрузки :)
0
Обычно ломается оно тогда, когда чинить времени уже нет)
0
угу. и «просто» — тот еще вопрос. ведь лошадок надо кормить каждый день, а не тогда, когда прокатиться захотелось.
и ЗИП возить с собой порой просто невозможно by design.
0
Вам не хватает производительности и фарша в голове, чтобы понять что такое «просто».
0
угу. я не хочу кормить лошадей (или нанимать людей), пока я в отпуске на месяц.
0
такое «просто» мне просто не нужно.
0
Просто — это не перелопачивать десяток менюшек, окошек и рюшечек, чтобы добраться до сути. Просто — это когда программа представляет собой просто директорию с файликами, а не размазывается по всей системе магическим образом. А то, что ты описал — это неудобно, а не «просто».
0
ничего, что противоречишь сам себе?
0
Я не противоречу. Это ты не способен понять, что хорошее и удобное — это не обязательно жыр и излишества.
0
эм. позволь спросить. катаешься по городу (или деревне, хз где ты живешь) на лошадках (оно ведь просто!), или на общественном транспорте? ;)
0
Я ещё раз повторю. Ты не понимаешь что такое просто (и наверно врядли поймёшь).
0
угу. абстрактное «просто» (и возможная красота инженерного/программерского, нужное подчеркнуть) меня волнует чуть менее чем совсем никак. мне главное удобно лично мне.
и если в вин7 мне удобно дернуть за заголовок в верх экрана и окно развернется на весь экран — это хорошо, удобно и просто. а в ХРени надо целиться и совершать лишние телодвижения.
или взять заголовок ближайшего окна и подергать из стороны в сторону чтобы свернуть все окна и увидеть рабочий стол — это тоже удобно и просто.
0
Это и есть лишние телодвижения. Ничего лучше простого нажатия на кнопку ещё не придумали.
0
мб и так. но мне удобнее целиться не в кнопку 16*16, а в заголовок 32*1000.
0
и если в вин7 мне удобно дернуть за заголовок в верх экрана и окно развернется на весь экран — это хорошо, удобно и просто.
Это удобно если с хрюшкой уже не работаешь. А иначе лучше не привыкать)
0
точно. одна засада — привыкаешь моментально.
у меня брат по прежнему юзает ХРюшу. как сажусь за его комп, каждый раз матерюсь, что такие удобные фишечки в этой ХРени не работают.
благо, это бывает достаточно редко.
0
Просто — это не перелопачивать десяток менюшек, окошек и рюшечек, чтобы добраться до сути.
тебе неудобно. и непривычно. хотя по сути, нехер многочисленным менюшкам мозолить глаза.
Просто — это когда программа представляет собой просто директорию с файликами, а не размазывается по всей системе магическим образом.
лучше пусть лежат где-нить подальше от глаз и не отвлекают внимание, когда мне нужно только подправить конфиг. вот нахер мне наблюдать все эти экзешники и дллки, когда меня иинтересует один-единственный инишник?
0
Где-то была хорошая картинка, как программист в очередной раз решил построить дом и в очередной раз получилось нечто с висящими в воздухе на подпорках пристройками, верёвочными лестницами, дверями на крышах, чрезвычайно некомпактно и нестабильно, с диким перерасходом материала. Очевидно тоже ставил требования вроде
пусть лежат где-нить подальше от глаз и не отвлекают внимание
0
недостаток проработки модели использования. и только.
вот только, боюсь, такой дом у вас из под пера и выйдет. потому, что веревочная лестница и дверь на крыше — это «красивое инженерое решение», и «вы ничего не понимаете».
+1
Пока что такие дома выходят лишь из под пера продвинутых умников с явами и оопами.
0
мы все еще о домах и машинках с лошадками, или уже о явах с оопами?
что за резкая смена темы?
0
Какая разница. Суть одна
Поколение «фастфуда» врядли сможет понять крик души хлебороба. Arduino, это «игрушка», «хобби», «только макетка- а уж в серию пойдёт специализированное изделие», «за простоту надо платить». С ЕГЭ тоже сначала поигрались, потом пустили в серию. Теперь все расплачиваемся. Я тоже вырастил детей на LEGO,- был молод и глуп. Теперь только я знаю, что планку с монтажными отверстиями можно изогнуть и получить простое и нестандартное решение, которое смогут повторить и другие моделисты. Они же, в первую очередь, ищут готовую деталь, не найдя которую, начинают городить огород из имеющихся шаблонов. И да, они делают свои конструкции, но в них нет ни простоты ни изящества решений. И это во всём, чего не возьмись. Пол века назад простенький Луноход гоняли. Теперь поумнели на новых технологиях и Фобос-Грунт даже не улетел
Был бы хоть грамм мозга (а не одна хихикалка), мог бы понять.
0
Теперь только я знаю
, что планку с монтажными отверстиями можно изогнуть и получить простое и нестандартное решение, которое смогут повторить и другие моделисты.
ЫЫЫыыы… Носитель ТАЙНОГО ЗНАНИЯ…
улыбнуло. надеюсь, не себя цитировали? ;)
но в них нет ни простоты ни изящества решений.
а может, шоры мешают их увидеть?
Был бы хоть грамм мозга (а не одна хихикалка), мог бы понять.
ну да, ну да. у вас ведь целых полтора килограмма этой серой субстанции…
0
а может, шоры мешают их увидеть?
А что видеть? Как вы яростно фапаете на всякие STM32 с USB и DSP на борту, но практический результат ограничивается запуском стандартных примеров (ну может 2 строчки поправить)?
Как комп с гигагерцами и гигабайтами едва ворочает вашими программными поделками?
Человек занимался моделизмом в совковых условиях, не имея ничего кроме говна и палок, тем не менее даже модели вертолётов удавались. Я вполне понимаю его чувства.
0
хм. стму стмово. я в равной степени юзаю и стм32 и стм8. вот от атмела да, давно убежал. по причинам, озвученным выше.
но практический результат ограничивается запуском стандартных примеров (ну может 2 строчки поправить)?
Как комп с гигагерцами и гигабайтами едва
ворочает вашими программными поделками?
не стоит судить заочно.
Человек занимался моделизмом в совковых условиях, не имея ничего кроме говна и палок, тем не менее даже модели вертолётов удавались.
ну, респект и уважуха. чо.
вот только это совершенно бесполезный опыт в нынешних реалиях.
0
вот только это совершенно бесполезный опыт в нынешних реалиях.
Угу, в нынешних реалиях важен опыт громче хихикать.
0
и петь о мифической «простоте» и «красоте решения».
угу.
0
при этом забивая на юзабилити.
пулю из говна конечно можно вылепить, но зачем?
0
и петь о мифической «простоте» и «красоте решения».
Потому что ты простого и красивого не видел, да и похоже, увидеть не способен.
Развитие для тебя может быть только таким.

А бывают люди, которые могут придумать такое

0
не сливайся уже окончательно.
и да, это развитие скорее твое. так и вижу картину: двадцать лет спустя на асме для тиньки и межки и с глобальной проблемой: на какой барахолке купить 2313.
0
Это ты сливаешься скорее.

двадцать лет спустя на асме для тиньки и межки и с глобальной проблемой: на какой барахолке купить 2313
Учитывая всеобщую тупость и дерьмовость современных поделок, через 20 лет может инженеров не остаться. Будет стадо обезьян, способных лишь хихикать и троллить друг друга.
0
хм. покажи
всеобщую тупость и дерьмовость современных поделок
0
Вот посмотри на это. Это из промышленной среды разработки.

Джоинты — нет, не слышали. Каждая линия идёт от точки к точке и это всё переплетается и запутывается. Даже так расположить стоит аццких усилий, потому что чтонить подвинешь — и всё расползается. Наложить друг на друга дорожки (из одного нетворка) среда не даёт, но сама с удовольствием располагает (в том числе из связи разных нетворков).
Зато да, оопы, новые технологии и т.п., даже «красивый» интерфейс со сглаживанием с поддержкой стилей(!)

Совковый школьник сам вполне мог собрать комп или зомбоящик, дай тока детальки. Много корпусов и большая схема не были помехой. Современным подавай ардуйню, и то три проводочка воткнуть без ошибки — подвиг.

А как тебе кабина аирбасовская? Пилоту РУС в левую руку, штурману — в правую. В критической ситуации РУС окажется последним средством, и пилот будет вынужден действовать левой рукой. Зато клава занимает главное место. Это нормальные люди вообще сделали?

Да тысячи этих примеров.
0
даже «красивый» интерфейс со сглаживанием с поддержкой стилей(!)
Да это-то как раз проще всего. Потому и делают.
Совковый школьник сам вполне мог собрать комп или зомбоящик, дай тока детальки.
Невелико, тащемта, достижение — собрать готовую схему. Это вон только SWG чисто свой комп проектировал. Ардуинщики хотя бы программу обычно сами разрабатывают.
0
ну, про ту типа «схему» даже говорить ничего не буду. т.к. получится только матом.

Совковый школьник сам вполне мог собрать комп или зомбоящик, дай тока детальки. Много корпусов и большая схема не были помехой. Современным подавай ардуйню, и то три проводочка воткнуть без ошибки — подвиг.
хм. от доступности элементной базы. неужели ты всерьез веришь, что расплодилось-бы такое количество совковых спектрумов и прочих микрош с орионами при доступности оригинальных ZX и таймексов?
а через двадцать лет подобные будут говорить «русские школьники с одной только ардуйней могли… (вписать нужное)»
+1
Ты не понимаешь главного — совковые школьники могли и хотели, сейчас же лишь бы попонтоваться. Многие занимаются электроникой, лишь чтобы выглядеть поилитней среди другого быдла. Кто-то из советских астрономов сказал «Человек отличается от свиньи тем, что иногда поднимает голову и смотрит на звёзды». Так вот сейчас звёзды уже мало кому нужны. Лениво потыкать проводками в ардуйню — и то подвиг и 100500 плюсиков на хабре.
0
Я считаю, ты несправедлив к современным школьникам.
0
сейчас же лишь бы попонтоваться.
мне вас очень жаль. искренне жаль. с какими вам приходится общаться.
у меня опыт общения сильно (диаметрально противоположный) другой.
впрочем, и те «совецццкие школьники» тоже делились очень сильно. кто начинал курить и бузать чуть не в пятом классе, а кто запускал ракеты и строил модельки. вы, очевидно, предпочитаете вспоминать только о вторых.
0
*бухать
0
Многие занимаются электроникой, лишь чтобы выглядеть поилитней среди другого быдла.
Я знавал таких в совковые времена. Они были, есть и будут.
+1
Ты не понимаешь главного — совковые школьники могли и хотели
Побухать, покурить и потрахаться. В основной своей массе.
+1
Хотя тебе наверно лурка ближе.
0
не поверишь.
0
и чем это красивее этого?
0
Эти ребята молодцы. Но энтузиастов очень мало осталось, больше любителей покричать у какого новомодного МК больше фарша.
0
но этого просто невозможно без «МК с больше фарша»
0
Это не главное. На чём запустить — в любом случае найдётся. Куда ценнее код, который может с пользой использовать этот фарш и производительность. Есть хорошая статья на эту тему.
0
отвечу двумя линками с хэппенса:
раз
два
читать последовательно.
0
Гм, насчет этого проекта не знаю, но многие подобные не заморачиваются контроллерами и сразу берут ПК. Обычно даже несколько.
+1
ну, что у собачки внутри вроде еще никто и не знает. я просто хотел намекнуть, что межке и тиньке с асмом в таком проекте место разве что в контроллере сервы с тупыми командами «повернуть на Х градусов» и не более.
0
Межка или тинька отличные штучки для небольших проектов с датчиками, всякими крутилками, светодиодиками и экранчиками. Они для этого подходят лучше, чем эти ваши армы. Если же понадобится 32 бита, возьму — это не проблема.
0
Да большинству из этих проектов вообще пофигу какой контроллер. Разница только в названии регистра, управляющего ножкой.
0
Таких проектов большинство. Если только под этими «да как ты не понимаешь, это больше фарша за меньшие деньги» было бы «я знаю, как это можно применить», но на самом деле «смотрите, какая у меня модная штучка, у кого такой нету — лузер».
0
нет. иначе. что ты сделаешь за два дня, я сделаю за два часа. и не в фарше и понтах дело.
0
Да не. Больше фарша = меньше ограничений. Под конкретный проект можно выбрать конкретный проц. Выбирая же проц «универсальный», под большинство планируемых проектов — лучше подобрать некоторый оптимум по цена/возможности. У тех же AVR это ATMEGA8, за что и популярна. Если же сравнивать с другими семействами — STM8 предлагает те же возможности по втрое меньшей цене, а STM32 — большие возможности при той же цене. Если я не знаю, для чего оно мне конкретно понадобится — разумней взять с запасом. Или, хотя бы, не переплачивая.
0
стм8. конкретно 003 — в три раза дешевле.
так зачем платить больше?
0
ну и мега и стм примерно сравнимы, но под стм пишется более легко и непринужденно. и быстрее. так зачем платить больше? (собственным временем)
0
но под стм пишется более легко и непринужденно. и быстрее.
Доказательства. Межка — весьма простая и продуманная. Всё делается лёгким движение. Другое дело, что в STM может быть что-то, чего нет в межке, впрочем и у межки есть плюсы.
0
угу. фигурный квотинг. легко.
впрочем и у межки есть плюсы.
Доказательства.
0
Ток ножек — 40 вместо 25.
Опора АЦП — 1 вместо 2.4.
Быстрый ШИМ — «силовые» тиньки имеют PLL для шима на 65 МГц.
Дифференциальный усилитель АЦП.

Железно полезные фичи. И ты так и не сказал почему под STM легче писать. Периферия более громоздкая и требует на порядок больше телодвижений. Общее адресное пространство? Неплохо, но требует более громоздких указателей. Мне и отдельные пространства не в напряг, не вижу большой беды в них.
0
Ток ножек — 40 вместо 25.
уже сказал. редко когда надо. светику и 5мА за глаза. а полевику 25-40мА погоды не сделают.
Опора АЦП — 1 вместо 2.4.
впереди в любом случае пара операционников стоит. так что без разницы к какому уровню приводить.
Быстрый ШИМ — «силовые» тиньки имеют PLL для шима на 65 МГц.
а 103 сам на 72МГц РАБОТАЕТ, а не только шим.
Дифференциальный усилитель АЦП.
вот про что не скажу, про то не скажу. ни в мегах, ни в стм ни разу не пригодилось.

Периферия более громоздкая и требует на порядок больше телодвижений.
при изучении ядра раз написал, и больше никаких телодвижений. зато скажем, таймеры, можно цеплять каскадом. очень удобно.
Общее адресное пространство?
это вообще киллер-фича.

плюс за сравнимые деньги больше флеша. так что
требует более громоздких указателей
не в тему чуть более чем полностью.
0
а полевику 25-40мА погоды не сделают.
Полевик будет меньше греться и сможет скоммутировать больший ток. Это значительная разница. А в разных светодиодных матричках с динамической развёрткой это просто сокровище. Если коэффициент коммутации — 8 или 16, 40 мА как раз и дадут 5 или 2,5 мА.
впереди в любом случае пара операционников стоит. так что без разницы к какому уровню приводить.
Но контроллеру нужно 2,4В. А LM358 (или LM324) при питании 3-3,3В даст размах всего 1,5-1,7В. Что межке хватит покрыть весь динамический диапазон, а STM потребует R2R усилителя.
а 103 сам на 72МГц РАБОТАЕТ, а не только шим.
Вот тут как раз надо вспомнить про цену — 40 рублей или 140. А не кричать, что STM8 на 2 рубля дешевле межки.
вот про что не скажу, про то не скажу. ни в мегах, ни в стм ни разу не пригодилось.
Значит ничего не делал. Измерения тока, куча разных датчиков, токовая петля — дифференциальный усилок во всём этом незаменим.
это вообще киллер-фича.
Не принципиальная. Немного облегчает жизнь, но и не бесплатно даётся.

В общем, похвастаться тебе особо нечем. Я вижу у межки неоспоримые преимущества, а у STM — мелкие удобства.
0
Что межке хватит покрыть весь динамический диапазон, а STM потребует R2R усилителя.
У STM32 разрядность АЦП на два бита больше. Откидываем старший бит и получаем все равно на бит больше, чем у AVR, но уже в желаемом диапазоне.
0
Шум и нелинейность влияют как раз таки на младшие биты.
0
Угу, но тут ситуация примерно одинакова у обоих камней. К тому же у STM32 есть еще один бит, который можно срезать снизу и получить разрешение как у AVR, в диапазоне как у AVR и с меньшим шумом.
0
Мне такое решение не нравится. Если уж делать, то делать хорошо, а не заниматься говноляпством.
0
Я бы не назвал говноляпством решение, которое ни в чем не уступает.
0
это не говноляпство.
это разумное расходование ресурсов.

задайся вопросом, почему китайца начинают массово применять стм?
а они ведь каждый децицент считают…
0
У STM32 разрядность АЦП на два бита больше
итого в четыре раза.
0
итого в четыре раза
Опять слова дурака.
0
сам иди туда.
0
Почему? Действительно вчетверо. Ну учитывая вдвое большую опору — примерно вдвое выше по напряжению.
0
Потому что младшие биты имеют меньшую ценность.
0
Ну так они и определяют разрешение! Разрешение по напряжению равно весу самого младшего бита.
0
В идеальном случае — да. Но у нас неидеальный АЦП. Теоретически АЦП может выдавать любое количество бит, но его приходится ограничивать. В AVR ограничили до 10, в STM — до 12. Это ещё не значит, что в STM лучше АЦП, может просто сдвинули ограничение в рекламных целях.
0
просто сдвинули ограничение в рекламных целях.
«может», или достоверно известно?
опять домыслы.
0
Может. Не известно, но и совершенно не исключено. В любом случае, отбрасывать старшие биты — ламерство и говноляпство.
0
вот и подтвердил домыслы и досужие размышления, основанные на неприятии «рекламных брошюрок».
0
Да, но твои домыслы основаны только на рекламных кричалках. Я же привожу хоть немного практические соображения.
0
ну если ты видишь только свои практические соображения…
мои соболезнования.
0
А что я ещё должен видеть? Летающих макаронных монстров? Нет, я стараюсь опираться на здравый смысл, а не на соображения модности и продвинутости.
0
А что я ещё должен видеть?
кажется, очевидно должно быть. новые возможности и сферы применения.
0
Ну, я периодически посматриваю на C4. Добавляю в корзину и удаляю, так и не придумав где применить. Они слишком громоздки и не имеют нормального софта, чтобы использовать повсеместно, а задачи, достойной 32-разрядного МК я пока не придумал.
0
хм. а может попробовать?
а то так и останешься в каменном веке… ;)
0
Можно и попробовать. Начать с книжки Тревора Мартина, даташиты прочитать. У меня лежат 8L и 32L дискавери, модуль для PB2, ещё китайская платка с 103VE и TFT 320240. Информация тоже вся нужная собрана. В целом, это требует каких-то усилий, но не так уж сложно. Если появится задача. Просто так не вижу смысла забивать голову лишней информацией. Кроме МК есть и более интересные детальки.
0
В любом случае, отбрасывать старшие биты — ламерство и говноляпство.
Забавно, но если посмотреть на звуковую дорожку DVD — там обычно отброшено порядка 3 старших бит (уровни не превышают +-3500 из доступных +-32767). А ими отнюдь не ламеры занимаются.
И да, запас битов на то и нужен, чтобы им распорядиться. Он позволяет мерять сигнал в половину диапазона без проигрыша в точности, например.
0
Там довольно серьёзные АЦП аудио-класса. В МК АЦП простенькие, и разбрасываться старшими битами — варварство.
0
Пожалуй, я утяну у evsi фразу:
Не порите чушь, ей больно.
0
Где именно чушь?
0
там, где вы ее порете, очевидно.
0
Там указаны параметры точности, они примерно на том же уровне, что и у AVR.
0
Полевик будет меньше греться и сможет скоммутировать больший ток. Это значительная разница. А в разных светодиодных матричках с динамической развёрткой это просто сокровище. Если коэффициент коммутации — 8 или 16, 40 мА как раз и дадут 5 или 2,5 мА.
в поделке можно и драйвер из биполярника поставить. в серии — разница мега-стм32 0,25грн, а биполярник 0,05грн.
Но контроллеру нужно 2,4В. А LM358 (или LM324) при питании 3-3,3В даст размах всего 1,5-1,7В. Что межке хватит покрыть весь динамический диапазон, а STM потребует R2R усилителя.
где нужен R2R, там цена операционника роли не играет. а для себя вообще вопрос не стоит.
Вот тут как раз надо вспомнить про цену — 40 рублей или 140. А не кричать, что STM8 на 2 рубля дешевле межки.
не 40 и 140, а примерно по вашему полтиннику (m8 vs 100c4, при этом заметьте разницу в возможностях.)
Значит ничего не делал. Измерения тока, куча разных датчиков, токовая петля — дифференциальный усилок во всём этом незаменим.
ну, такого не делал. не буду спорить о вкусе устриц, которых не ел.
Немного облегчает жизнь,
сильно облегчает жизнь. небесплатно с точки зрения флеша да. но на цене камня оно не отражается. так что бесплатно в общем зачете.

Я вижу у межки неоспоримые преимущества,
и опять сплошной субъективизм.
0
в поделке можно и драйвер из биполярника поставить. в серии — разница мега-стм32 0,25грн, а биполярник 0,05грн.
Не всегда. Полевик более универсален, для маленького DC/DC он куда лучше подойдёт, чем биполярник или дарлингтончик (если тот вообще подойдёт).
где нужен R2R, там цена операционника роли не играет. а для себя вообще вопрос не стоит.
Но разница в цене между R2R и обычным с лихвой окупит разницу между микросхемками (к тому же, счетверённые R2R — встречаются реже, а LM324 — стоит копейки и есть везде). А нужен ОУ не так уж редко.
не 40 и 140, а примерно по вашему полтиннику (m8 vs 100c4, при этом заметьте разницу в возможностях.)
100C4 — до 24 МГц, а быстрый шим — в тиньках x4, x5. Они специально заточены под силовое применение и стоят дешевле m8.
сильно облегчает жизнь.
Ну в каком месте сильно? Обращаешься напрямую вместо pgm_read_… и функции для строк придётся продублировать (строковая библиотека есть в avr-libc, так что только для вывода). Дел на 5 минут. Это ерундовое преимущество.
0
Не всегда. Полевик более универсален, для маленького DC/DC он куда лучше подойдёт, чем биполярник или дарлингтончик (если тот вообще подойдёт).
ты не понял. для полевика драйвер.
Но разница в цене между R2R и обычным с лихвой окупит разницу между микросхемками (к тому же, счетверённые R2R — встречаются реже, а LM324 — стоит копейки и есть везде). А нужен ОУ не так уж редко.
ну началось… счетверенный… так можно любоое оправдание найти.
100C4 — до 24 МГц, а быстрый шим — в тиньках x4, x5. Они специально заточены под силовое применение и стоят дешевле m8.
угу. а вот здесь перекос у нас. эти тиньки стоят дороже м8…
Обращаешься напрямую вместо pgm_read_…
да.
Дел на 5 минут.
смотря как применять.
0
ты не понял. для полевика драйвер.
Ладно, но для матрички понадобится много драйверов.
ну началось… счетверенный… так можно любоое оправдание найти.
А что, повторитель на входе для согласования, low-pass фильтр, пороговый детектор и триггер шмитта для него. Вот уже 4 штучки заюзали.
угу. а вот здесь перекос у нас. эти тиньки стоят дороже м8…
Нет, не дороже. Разве что на уровне.
0
Ладно, но для матрички понадобится много драйверов.
А матричка и так вылетает, межка не способна прокормить более 5 выводов под полной нагрузкой.
0
Смотря какая. Межки в TQFP, имеющие 4 питания смогут раза в 2 больше.
0
ну, матрица вообще не в кассу. ей и так нужна кучка россыпи. плюс-минус кГ роли не ин=грает.
Нет, не дороже. Разве что на уровне.
как Vga ниже верно заметил, 45 тиньки стоят как мега8 (т.е. 100с4), а 85 тинька уже как 103с4.
0
и да. вспомни о таком параметре, как общий ток через минус. а он, емнип, около 100мА. т.е. 2,5@40mA выхода.
0
Он одинаковый для плюса и минуса. У разных межек от 200 до 400 мА.
0
ну, мог и забыть.
но и
200/40=5
400/40=10
и это в идеальном случае только на порты. дальше уже додумайте самостоятельно.
0
Как раз 5-10 семисегментников с приличной яркостью.
0
поехали практически. общий катод/анод 5мА/сегмент — абсолютный и недостижимый максимум 40мА. это если горит восьмерка с точкой.
а теперь, ВНИМАНИЕ! ВОПРОС!
часто нужно зажигать все сегменты с точкой?
правильный ответ: чуть менее, чем никогда.
0
Для общего катода или анода как раз понадобятся ключи. Так что в статике 40 мА/сегмент и 320 мА на индикатор. При коммутации 1/6 (например) — уже 6,5 мА на сегмент.
часто нужно зажигать все сегменты с точкой?
А почему бы и нет? Восьмёрка — обычная цифра, точка в принципе погоды не делает. Девятка, шестёрка — тоже горят почти все сегменты.
0
ну, матрица вообще не в кассу. ей и так нужна кучка россыпи. плюс-минус кГ роли не ин=грает.
Ну не матрица, а, допустим, табло семисегментников. Межка сможет ими управлять напрямую и они будут светиться ярко.
45 тиньки стоят как мега8 (т.е. 100с4)
Ладно, но у 45 тиньки есть 64 МГц ШИМ, мощные ножки, дифференциальный усилитель, и встроенная опора АЦП 1.1В или 2.56В, а у C4 ничего этого нету.
85 тинька уже как 103с4
Нет, дешевле в 1,5-2 раза. Да и 8 КБ — довольно много для области применения этой тиньки 2-4 КБ — нормально.
0
семисегментниками вообще можно чем угодно управлять.
ну, выбрал удобные тебе объекты сравнения.
0
быстрый шим — в тиньках x4, x5. Они специально заточены под силовое применение и стоят дешевле m8.
Да ну? По моим данным TINY45 стоит как MEGA8, а TINY85 где-то вдвое дороже.
0
Чтобы сэкономить на остальном. У межки более мощные ножки — 40мА, а у STM8 — только 25мА. Можно подключить напрямую то, для чего бы понадобился усилитель. А если управлять ножкой полевичком, то межка будет его открывать и закрывать энергичней, что возможно, позволит отказаться от внешнего драйвера полевичка (а они дорогие). У межки опора АЦП от 1В, у STM (насколько я помню или от 2.4В или вообще прибито к питанию). Это позволит сэкономить на R2R ОУ, а поставить обычный LM358. Из многих таких нюансов и состоит мой выбор. Только у дураков аргументы вроде «в три раза дешевле». Да и то наверно смотрел STM8 оптом, а AVR — в чип-дипе.
0
У межки более мощные ножки — 40мА, а у STM8 — только 25мА
хм. и часто оно нужно?
У межки опора АЦП от 1В, у STM (насколько я помню или от 2.4В или вообще прибито к питанию).
тоже очень спорно, т.к. в любом случае или усилитель или повторитель стоит.
Только у дураков аргументы вроде «в три раза дешевле».
сам дурак :-P
Да и то наверно смотрел STM8 оптом, а AVR — в чип-дипе.
нет, в одном месте:
003 3,75грн
мега8 10,75грн
tiny13 6грн
дык, не сравнивайте тиньку13 и 003.
0
STM32F100C4T6B 11,00грн
0
добавлю еще плюсик к стм.
поножечная совместимость в линейках между корпусами.
стало тесно в сотой серии и понадобился USB — легким движением фена махнем 100c4 на 103с6 или что-нить из 2хх или 3хх или 4хх линейки.
атмелу такое и не снилось.
0
поножечная совместимость в линейках между корпусами.
У межек x8 тоже поножечная совместимость. У тинек x4, x5, x61 — аналогично. Периферия разная, но разные чипы заточены под разные задачи. А не под одну — «вызвать вау-эффект» у потреблятеля.
стало тесно в сотой серии и понадобился USB — легким движением фена махнем 100c4 на 103с6 или что-нить из 2хх или 3хх или 4хх линейки.
И тем же движением разведётся на плате USB?

Приведу Горниста снова.
Совсем Гамлетовский вопрос — считать ли это недостатком или нет? Менять схемотехнику или нет? Вообще, в процессе построения чего-нибудь, такие вопросы возникают очень часто. И если ответ — Да, это косяк, и не пойдёт, то на прототипе появляются надрезы ножом и проволочные перемычки. Всё равно прототип полетит в мусорную корзину. И ещё один, и ещё. Потому что вдруг оказывается, что расположение компонент не даёт сунуть плату в корпус. А потом — что вот тот транзистор греется, ну и фиг бы с ним, только рядом расположенная микросхема протестует. Когда нескольким прототипам становится тесно в мусорнице, появляется нечто, отдалённо похожее на конечный результат. Это — бэта, и её предназначение — полевые испытания. Как правило, после них в мусорке становится теснее, а чертежи опять переделываются. И ещё несколько итераций — вот так, в общих чертах выглядит процесс проектирования.
Вот так делаются устройства. А не «легким движением фена махнем 100c4 на 103с6 или что-нить из 2хх или 3хх или 4хх линейки.»
0
У межек x8 тоже поножечная совместимость. У тинек x4, x5, x61 — аналогично.
угу. при всем богатстве выбора другой альтернативы нет. заебись выбор — 4-8-16кил и… И ФФСЁ!
И тем же движением разведётся на плате USB?
нет. это стоило предусмотреть при разводке. впрочем, у меня пара девайсов нормально на «не предусмотренном» USB (проводками) успешно трудятся. 1.1 — его любым первым попавшимся под руку огрызком прокинуть можно.

цитата — откровенное говно. т.к:
Совсем Гамлетовский вопрос — считать ли это недостатком или нет? Менять схемотехнику или нет? Вообще, в процессе построения чего-нибудь, такие вопросы возникают очень часто. И если ответ — Да, это косяк, и не пойдёт, то на прототипе появляются надрезы ножом и проволочные перемычки. Всё равно прототип полетит в мусорную корзину. И ещё один, и ещё.
это все решается на этапе макетирования. угу. ненавистные ардуины, олимексины, свои платки, беспайка, кучки проводков, для чувствительных к разводке участков — свои мелкие платки на проводках.
И ещё один, и ещё. Потому что вдруг оказывается, что расположение компонент не даёт сунуть плату в корпус.
это вообще за пределами добра и зла. экспорт в солид (Да! со всеми моделями!) и крути в корпусе.
А потом — что вот тот транзистор греется, ну и фиг бы с ним, только рядом расположенная микросхема протестует.
мнда. про тепловые режимы, похоже, не слышали. бывает.

в общем, это путь самоделкина.
у меня обычно максимум пара итераций.
только вот засада — вам софт еще освоить надо…
0
Не удаётся предусмотреть всё. Транзистор внезапно начинает греться сильнее, чем казалось теоретически. Бывают и просто ошибки. Только тому, кто ничего не делает всё кажется так просто.
0
макетирование-прототипирование зачем?
0
А не под одну — «вызвать вау-эффект» у потреблятеля.
Да, именно на это расчитаны говномежки. СТМ-ки же сделаны людми и для людей, так, что бы ими было удобно пользоваться, а не упражняться в переразводке платы каждый раз, как только оказалось, что не хватает периферии или нужна частота побольше. Что бы писать, думая о том, как решить задачу, а не о том, влезет ли прошивка.
0
Не думая и забивая на оптимизацию ни у кого ещё ничего хорошего сделать не получилось. Гонять МК на максимальной частоте как правило смысла нет. 1 МГц в большинстве случаев более, чем достаточно.
0
1 МГц в большинстве случаев более, чем достаточно.
640КВ хватит всем и всегда
:))))
0
Не думая и забивая на оптимизацию ни у кого ещё ничего хорошего сделать не получилось.
«Не думая» это ваши тараканы, а на оптимизацию забивають весьма часто. Что никак не мешает получать хорошие продукты в итоге.
0
Что никак не мешает получать хорошие продукты в итоге.
Хорошие — для их продавца? Для тех, кто ими пользуется и вынужден терпеть их мягко говоря, неторопливость, «хорошие продукты» звучит, как насмешка.
Кроме того, оптимизация — это часто ещё и упрощение. А оно повышает надёжность.
«Не думая» это ваши тараканы
Я не представляю как думая можно не уложиться по периферии, да ещё и так, что в случае AVR пришлось бы переразводить, а в случае STM — нет.
0
Хорошие — для их продавца?
Для пользователя.
Для тех, кто ими пользуется и вынужден терпеть их мягко говоря, неторопливость, «хорошие продукты» звучит, как насмешка.
С чего вы решили, что эти продукты неторопливы?
Я не представляю как думая можно не уложиться по периферии, да ещё и так, что в случае AVR пришлось бы переразводить, а в случае STM — нет.
Ну подумайте еще.
0
Для тех, кто ими пользуется и вынужден терпеть их мягко говоря, неторопливость
В эмбеде неторопливы обычно как раз интерфейсы на хилых МК с суперциклом внутре. Часто пока все остальное не обработает — новый ввод не принимает. Этим еще отличались старые прошивки для DSO Nano, кстати. Благо нашелся все же один программер с руками не из жопы — BenF.
0
В эмбеде неторопливы обычно как раз интерфейсы на хилых МК с суперциклом внутре.
На компе многие проги очень неторопливы, хотя они запускаются на весьма не хилом «МК», а внутре — потоки, явы, оопы и xml-и.
0
а было бы оно с суперциклом, так вообще реакции не дождались.
0
а было бы оно с суперциклом
Одно другому не мешает. В программках, написанных на новомодных C++ и Delphi очень часто вместо нормальной обработки событий тупо запускают таймер, который каждые 15 мс (разрешение стандартного таймера в винде) проверяет условие и при необходимости выполняет действие, что по сути мало чем отличается от архитектуры с суперциклом. Также видел статью о подобном решении в какой-то новомодной IDE (JetBrains или что-то в таком роде), что вызывало дикие тормоза в определённых условиях. Подробностей, правда, не помню.
так вообще реакции не дождались
В нормально написанной программке для МК, период главного цикла — несколько миллисекунд. В плохо написанной, разумеется, может быть как угодно медленно. Но и, как видишь, на компе с гигагерцами и гигабайтами можно написать также плохо.
И чем больше наворочено всяких фреймворков, оопов и прочего, тем сложнее сделать просто хорошо.
0
В программках, написанных на новомодных C++ и Delphi очень часто
Вопрос: в скольких программах вы это видели?
0
Вопрос: в скольких программах вы это видели?
Я их достаточно расковырял
0
Я их достаточно расковырял
Я задал вполне конкретный вопрос. «Достаточно», в вашем исполнении, увы, не аргумент.
0
Я не буду отчитываться в своей практике реверсинга, но опыта у мя хватает.
0
Что-то мне подсказывает, что речь идет о единицах программ. И я совсем не удивлюсь, если окажется, что и написанное вами всего-лишь неправильная интерпретация увиденного в коде.
0
В программках, написанных на новомодных C++ и Delphi очень часто вместо нормальной обработки событий тупо запускают таймер, который каждые 15 мс (разрешение стандартного таймера в винде) проверяет условие и при необходимости выполняет действие
Ты еще скажи, что эти горе-программеры на сях напишут по другом. Они еще и Sleep'ов натолкают. И в некоторых случаях — вполне нормальный подход. Я и сам иногда так делаю, тут, например. Разрешение кстати, по дефолту, 10мс.
В нормально написанной программке для МК, период главного цикла — несколько миллисекунд.
Ну, во первых — в нормально написанной. А во вторых иной раз оно запускает длительные задачи с delay()-ми, и пока все не отделэйится — интерфейс в заморозке. На DSO Nano это приводило к тормознутости девайса при медленной развертке, а некоторые другие решения, связанные все с тем же суперциклом — к кривой работе собственно осциллографа на любой развертке. Благо, потом пришел нормальный программер. У него, может, и суперцикл, но он хоть готовить его умеет.
0
Э… C++ уже новомодный?
0
А так и есть, кстати говоря. Только не в больших прогах, а в однопоточной мелочи.
0
внутре — потоки, явы, оопы и xml-и.
Вот только проблема вовсе не в них, а в том, что итоговая сложность софта сейчас весьма велика. Опять-таки, в этой сложности виноваты вовсе не перечисленные вами инструменты.

P.S. вообще у вас странная позиция. вы хаете инструменты, хотя, даже если придерживаться ваших взглядов, хаять имеет смысл людей, которые которые ими пользоваться.
0
вы хаете инструменты
Я бы не назвал всё эти инструментами. Инструменты должны облегчать жизнь, а эти — усложняют.
хаять имеет смысл людей, которые которые ими пользоваться
Да, разумеется. Проблема в мозгах, а плохие программы — просто симптом. Проблема в том, что люди разучились мыслить так



Зато буквально молятся на такое и такое.

И это печально, конечно, рано или поздно этот пузырь лопнет. Но боюсь себе представить до чего дойдёт перед этим, наверно HelloWorld будет час рассчитываться на самом современном суперкомпе.
0
Инструменты должны облегчать жизнь, а эти — усложняют.
Вы продолжаете говорить глупости о вещах, в которых ничего не понимаете.
+1
Да тебе всё бред, чушь и глупости.
Вот в соседнем топике человек рассуждает о каде.
Технологии клиента/сервера определены на текущий момент.
Деплой у клиента посредством приложения-деплоера. Для мобильных платформ — через сторы. Формирование репозитория клиента — на основании файлов проекта, использовать БД смысла не вижу — уже не раз сталкивался, что из за настроек безопасности разворачивается некорректно.
Если говорить о ресурсах клиентского приложения — то планирую минимальные около 2 ядер и 2 Гб ОЗУ. Что касается сервера — волнует мало — 4 т.р. за 8 ядер и 32 Гб ОЗУ — не деньги.
Синхронизация посредством запроса контрольной суммы и получения через транспортный уровень списка обновлений установленных компонентов. Но, ИМХО, вопрос был связан с преположением, что все это добро развернет херову тучу БД и сервисов.
Вот это — бред, чушь и глупости.

Вот у мя лежит в папке Sprint-Layout, который не требует никаких установок и деплоев, гигагерцев и гигабайтов, серверов, интернетов, репозиториев, виртуальных машин. Занимает 1 МБ. Вот такими должны быть все программы.

А этим вашим «инструментам», в которых я «ничего не понимаю» место в помойке.
0
Sprint-Layout
Впрочем, ты сейчас начнёшь рассказывать какое он устаревшее говно. Ну, есть nanoCAD, который тоже один небольшой запускаемый файлик. А ещё uTorrent и другие программки. Важно не то, какого размера задача, а насколько вменяемые люди над ней работают.
0
Впрочем, ты сейчас начнёшь рассказывать какое он устаревшее говно.
Нет, я просто скажу, что эта софтина ничего толком не умеет, а потому не представляет практической ценности.
Важно не то, какого размера задача, а насколько вменяемые люди над ней работают.
И какой объем функциональности она реализует. И насколько сложные задачи решает. Все вместе влияет на результат.
0
Вот у мя лежит в папке Sprint-Layout, который не требует никаких установок и деплоев, гигагерцев и гигабайтов, серверов, интернетов, репозиториев, виртуальных машин.
Угу. И для реального применения практически непригодный.
Занимает 1 МБ. Вот такими должны быть все программы.
Слава Богу, не все программы настолько бесполезны как эта.
А этим вашим «инструментам», в которых я «ничего не понимаю» место в помойке.
Там место вашим высказываниям о них. Как раз потому, что вы в них ничего не понимаете.
0
Угу. И для реального применения практически непригодный.
Для реального применения непригодны ваши оопы и паттерны.

На ламповых компах моделировали ядерные реакции и космические полёты. Думали, станут процессоры пошустрей — и искуственный интеллект осилим. А что получили? Вот я открыл гугл, чтобы найти эту картинку



А гугл даже нормально страницу с картинками не может осилить. Чуть быстрее начнёшь прокручивать — «сценарий не отвечает».

И при этом ты говоришь, что я ничего не понимаю в ваших инструментах. Что можно не понимать, если результат налицо?

Вот ты хорошо понимаешь, как винда управляет памятью? Думаю, в общих чертах (хотя это не принципиально). Вот есть 3 хороших статьи на эту тему (1, 2, 3). Человек их написал, потому что ему надоели «неграмотные» заявления вроде «почему винда начинает свопиться, даже если свободной памяти полно». Вот, допустим, я почитал и узнал смысл такого поведения винды. И что, винда от этого начнёт лучше работать? Нет. Также и будет выбрасывать из памяти приложения, при сколько нибудь заметной дисковой активности. Всё, что изменилось — я теперь могу описать явление более точно с технической точки зрения, но винда всё также будет свопиться и тормозить. От того, что я «ничего в них не понимаю», твои любимые «инструменты» не станут лучше. Софт будет всё больше жиреть, и требовать всё больших ресурсов, а чтобы в нём разобраться будет требоваться всё больше усилий. До тех пор, пока софт станет настолько глючным, кривым и бесполезным, что самые твердолобые сторонники яв и оопов не смогут закрывать глаза и отмахиваться аргументами вида «потому, что вы в них ничего не понимаете».

Угу. И для реального применения практически непригодный.
Я не развожу материнские платы, а одну-двухстороннюю платку осилю. Я лет в 12 разводил довольно большие платки карандашом на миллиметровки, так что и с SL справлюсь.

Там место вашим высказываниям о них. Как раз потому, что вы в них ничего не понимаете.
Если история развивается по спирали, то ПО просто летит в какую-то жопу. Учитывая, что от ПО зависят все основные отрасли, так можно и в каменный век вернуться. Тогда уж точно любые высказывания окажутся на помойке. Станут актуальнее простые вопросы о выживании.
0
На ламповых компах моделировали ядерные реакции и космические полёты.
Это проще вычислительно, чем кажется на первый взгляд. К тому же, отдельный вопрос, сколько времени они это моделирование выполняли. Нынче ж хочется, чтобы полет считался в масштабе времени х100 к реальному, при этом еще ракету рисовал и давал кербалом вокруг нее полетать.
До тех пор, пока софт станет настолько глючным, кривым и бесполезным, что самые твердолобые сторонники яв и оопов не смогут закрывать глаза и отмахиваться аргументами вида «потому, что вы в них ничего не понимаете».
Под ООП давно уже копают. Только не со стороны твоего любимого С, а со стороны более сложных парадигм. ФП, например, набирает популярность.
0
Для реального применения непригодны ваши оопы и паттерны.
Что-то список виновных у вас постоянно меняется. Вы бы определились что-ли.
И при этом ты говоришь, что я ничего не понимаю в ваших инструментах. Что можно не понимать, если результат налицо?
Ваше непонимание приводит к тому, что вы вешаете всех собак на инструменты, хотя они тут совершенно ни при чем.
От того, что я «ничего в них не понимаю», твои любимые «инструменты» не станут лучше.
Равно как не станут хуже. А то, что вы в них ничего не понимаете приводит лишь к тому, что вы с бессмыссленным упорством продолжаете повторять одни и те же глупости.
0
Слава Богу, не все программы настолько бесполезны как эта.
Да ладно. Нормальный молоток, полочку для специй дома сколотить.
0
Вот у мя лежит в папке Sprint-Layout, который не требует никаких установок и деплоев, гигагерцев и гигабайтов, серверов, интернетов, репозиториев, виртуальных машин.

Угу. И для реального применения практически непригодный.
Ты это только podkassetnik-у не говори, а то мужик не в курсе :)))).
0
Ты это только podkassetnik-у не говори, а то мужик не в курсе :)))).
Да ладно, платы можно и в пейнте рисовать, при желании. Вопрос только в трудозатратах.
0
Раньше и на бумаге рисовали, руками, и по сложности такие, что волосы шевелятся. Но эти подвиги повторять не очень хочется, особенно при наличии инструментов.
0
Думаю, сейчас аналогичная плата разводится неспешно и с перекурами за пару дней, если не меньше. Иначе говоря, ровно та же ситуация — подходящий инструмент позволяет понизить сложность задачи и время на ее решение. Или при аналогичных затратах времени и сил решать гараздо более сложные задачи. Хотя, конечно, какой-нибудь альтиум вместо труЪ карандаша и кальки это ересь, дань моде, жирный и неповоротливый пожиратель электроэнергии и так далее по списку.
0
Хотя, конечно, какой-нибудь альтиум вместо труЪ карандаша и кальки это ересь, дань моде, жирный и неповоротливый пожиратель электроэнергии и так далее по списку.
с полупрозрачностями и глянцем :)))
0
Дык я о том и говорю. В эту струю можно и кузнецов включить, которые блох подковывали. Только раньше это чудом было, а сейчас скучный технологический процесс.

Сложности (и абстракции) растут пропорционально потребностям. Не зря учёные прогнозируют такую ситуацию, как «технологическая сингулярность», т.е. когда абстракции достигают такого уровня, когда человек уже не способен их понять.Грубо говоря машины пишут код (или делают архитектуру), суть которого человек уже не понимает.
0
Ну я думаю приведенные требования клиента таки завышены, хотя все зависит от криворукости автора. Деплоить unity3d вполне можно и из архивчика, но делать инсталлятор все равно правильней, ибо так положено в винде. Типа стандарт.
Слай там мало весит потому, что это MS Paint. Автор же замахивается на фотошоп. Оно будет тяжелее тупо за счет большего количества функций и куда больших библиотек (в слае только футпринты, нормальные кады хранят гораздо больше).
0
Статьи, в чем-то, конечно, правы, но если ты хочешь сделать не полочку на стену, а миллион таких полочек и продать — тебе таки понадобится та самая фабрика.
0
хм. и часто оно нужно?
Обычная фича, не менее полезная, чем другие.
тоже очень спорно, т.к. в любом случае или усилитель или повторитель стоит.
Всё это детали, которые могут быть важными. Мне межка в целом кажется более продуманной и удобной, поэтому её и использую.
003 3,75грн
мега8 10,75грн
tiny13 6грн
дык, не сравнивайте тиньку13 и 003.
Ну может в твоём месте и так. Я закупаюсь в чип-нн и в компэле, в обоих местах и то и другое примерно одинаково.
0
Обычная фича, не менее полезная, чем другие.
но и не более полезная чем другие.
Мне межка в целом кажется более продуманной и удобной, поэтому её и использую.
в общем исключительно субъективно.
Ну может в твоём месте и так.
kosmodrom.ua
проверяй сам. последнее время в инете у них реальные цифры. я вообще перед выходом закидываю позиции на телефон с ценами и отдаю в руки. расхождений не бывает.
0
в общем исключительно субъективно.
Я это не из пальца высосал, а понял на практике. Я не сужу о детальках по рекламным лозунгам вроде «больше фарша по низкой цене».
0
что за очередные инсинуации?
0
У межки опора АЦП от 1В, у STM (насколько я помню или от 2.4В или вообще прибито к питанию).
В мелких корпусах == питанию, в корпусах от 100 ног и больше — отдельный вход опоры.
0
Где-то была хорошая картинка, как программист в очередной раз решил построить дом и в очередной раз получилось нечто с висящими в воздухе на подпорках пристройками, верёвочными лестницами, дверями на крышах, чрезвычайно некомпактно и нестабильно, с диким перерасходом материала.
Это критика не программистов. Впрочем, вам этого не понять.
0
Упрощение — это не замена калькулятора на счёты! Это уменьшение запутанности, избыточности, излишеств.

Смысл термина в отсутствии переплетенности, запутанности, а не в количественных характеристиках. И самое главное — простота объективна.
0
Упрощение — это не замена калькулятора на счёты

Ну, Вы же поднимете, что пример с лошадьми и повозкой утрирован (как и Ваш пример со счетами).

А вот калькулятор и автомобиль – вполне актуальный пример. Их базовая концепция практически не менялась с момента появления на свет, но функциональные требования к данным устройствам постоянно возрастают. И, чтобы удовлетворять этим требованиям, приходиться усложнять устройство.
0
Ну, с веселыми троллями все понятно, но ты правда думаешь, что сможешь переубедить Lifelover'а?)
0
а похихикать? ;)
0
Лучше бы моск хоть раз заюзал.
0
симметрично.
0
лайфлавер слился!!!
0
Ты и есть веселый тролль ;) А вот e_mc2 производит впечатление адекватного человека. Хотя, возможно он просто не столь толстый.
0
нуничесе!
откуда такие выводы?
0
Ну, эта, я тут не первый день за вами наблюдаю, ага)
А, не, таки тролль. Просто адекватный, даже слишком)
0
угу. симмерично.
но не потроллить тролля — себя не уважать.
тем более, это весело.
0
Ну, фанатик не тролль. Впрочем, все равно весело.
0
кстати. я вот не понимаю оценок.
покажи в моих рассуждениях пару примеров трололо комментов, направленных на разжигание срача.
0
С этой точки зрения тут с труЪ троллями вообще туговато.
0
а где на них можно посмотреть?
0
evsi потыкай, уж он-то знает где троллями полакомиться можно)
0
ну, где их отловить — то известно.
но ты ведь заявил:
С этой точки зрения тут с труЪ троллями вообще туговато.
значит, знаешь где отловить трушных.
0
Нет, я только имею о них некоторое представление.
0
ОК. проехали. тогда хоть дай определение
труЪ тролля
0
Ну вот например кусочек определения.
0
а, типа разжигания срачей? ;)
ну да, у меня чуть другое определение. ближе к лурковскому, хоть и с вариациями.
0
но ты правда думаешь, что сможешь переубедить Lifelover'а

Нет. Переубедить его не реально. Но молча игнорировать его комментарии тоже, как-то, не интересно :)
0
И самое главное — простота объективна.
Не порите чушь, ей больно.
0
Это тоже цитата из Дейкстры вроде. Только вырванная из контекста.
0
Это не мои слова. Впрочем, начало статьи стоило бы выбивать на лбу каждому программисту. Дальше же идёт какая-то скучная ерунда про лиспы и подобное.
0
Это не мои слова.
Угу. Вы их просто не поняли.
Впрочем, начало статьи стоило бы выбивать на лбу каждому программисту.
С учетом того, что вы ничего в прочитанном не поняли, рекомендация, мягко говоря, спорная.
Дальше же идёт какая-то скучная ерунда про лиспы и подобное.
Вот-вот. Сложность решаемых задач никуда не девается и постоянно растет. Для того, что бы еще больше поднять уровень абстракции и понизить сложность и делаются инструменты типа Clojure. Вот только сами подобные инструменты отнюдь не просты, ни концептуально, ни в реализации.

Прогресс это бесконечный процесс поддержания простоты на прежнем уровне путем повышения уровня абстракции при решении задач. Вы можете с этим не соглашаться и молоть ерунду типа «простота объективна», но именно так и обстоят дела в реальной жизни.
0
Мне кажется, это ты так и не понял из статьи в чём разница между простотой и лёгкостью.
0
Мне кажется, это ты так и не понял из статьи в чём разница между простотой и лёгкостью.
Я-то понял, а вы?
0
По крайней мере, именно оттуда выражение «простота объективна». Написано вполне ясным языком, я не вижу что можно не понять.
Кроме того, лучше этой статьи я ничего не читал. Подписался бы под каждым предложением, а последняя строчка — и вовсе настоящий клад.
0
По крайней мере, именно оттуда выражение «простота объективна».
Да, вы выхватили фразу из контекста. Но так и поняли к чему она там.
0
Те, кто делают софт какие-то окончательно невменяемые стали.
То есть виноваты именно они? Мысль о том, что софт, по большому счету, пишется под потребности максимального количества потребителей вас не посещала?
0
Софт сейчас пишется для зарабатывания бабла. Пользователи всем безразличны.
0
открою страшную тайну: ВСЕ (ну, почти) делается для зарабатывания бабла. в прямом или слегка завуалированном виде.
0
Софт сейчас пишется для зарабатывания бабла. Пользователи всем безразличны.
Не порите чушь, ей больно. Бабло платят именно пользователи, так что они не могут быть всем безразличны.
0
Взаимоисключающие утверждения.
0
сегодня компьютер на работе установил какие-то обновления потихоньку, а потом требовал перезагрузиться. Причем в ультимативной форме.

и далее по тексту
херь неведомая, т.к.:
1) винда (а по тексту и поведению похоже она) позволяет отложить ребут на 10мин/1час/4часа. всего-то пару раз за рабочий день нажать пимпочку.
2)
Написал установка обновлений, не выключайте компьютер
происходит при загрузке компа. т.е. после биоса смело тушим комп кнопкой, и уже следующим утром пока пьем кофе, винда завершает установку обновлений.

в общем, пример — херь от школоло которое не понимает как ставятся апдейты у винды. и читать оно не умеет. и даже о работе компа не имет ни малейшего понятия.
-1
1) винда (а по тексту и поведению похоже она) позволяет отложить ребут на 10мин/1час/4часа. всего-то пару раз
Новая. У ХР винапдейт нечто практически неуправляемое)
происходит при загрузке компа. т.е. после биоса смело тушим комп кнопкой
Да не, ставит оно как раз во время «завершения работы». Изрядно нервирует иногда. Проще запретить автоустановку обновлений и ставить их перед тем, как собрался перезагрузиться.

Вообще, в целом поведение Windows Update на Windows XP описано очень точно.
+1
ну хз. мог и подзабыть поведение хрюши.
а вот семерка — как я описал. хотя перед выключением тоже есть какая то устаоновка, но совсем не критичная. около пяти минут максимум.
0
В семёрке своих косяков ещё больше.
0
пруфы в студию.
я очень долго сопротивлялся переходу на семерку. но с переходом нашел намного больше плюсов. как с точки зрения UI, так и под капотом.
каждый раз, когда пользуюсь технологическим компом (семерка на нем не идет, потому ХРень стоит), каждый раз громко матерюсь.
0
А я сидел под семёркой несколько месяцев — сраная нвидиа забила на драйвера GT555M для XP. Такое дерьмо. В XP-то настройки распиханы по всяким «local security polices», которые в самой дальней заднице, до некоторых не доберёшься пока не поснимаешь всякие галочки «use simple file sharing (recommended)», не говоря уж о стандартных идиотизмах вроде скрытия расширений файлов. В 7 добавили ещё один слой дибильных окошек и рюшечек, под которыми спрятаны обычные настройки. С таким удовольствием вернулся на XP (ну и на нормальный моник после сраного TN).
0
В 7 добавили ещё один слой дибильных окошек и рюшечек, под которыми спрятаны обычные настройки.
пруф ежедневно мешающих окошек в студию!
0
Да нажми в Win+Break. В XP получишь настройки системы, в 7 — какую-то дибильную портянку с какими-то дурацкими «типичными задачами». Я сам могу решить какая задача типична, а какая нет, блин.
0
Да нажми в Win+Break.
оно каждый день нужно?
оно нужно ровно один раз — при установке винды с нуля. а там лишний клик не играет ровно никакой роли.
+1
Не, ну до некоторых старых настроек в семерке правда докопаться сложно. Каждый раз заново вспоминаю как в «подключения» попасть, например, или где состояние текущего посмотреть. С трудом нашел окно настройки джойстиков, потом опять забыл и искал заново :) Панель управления там сильно перекроили. Не скажу впрочем, что стало хуже, но непривычно — да.
+1
трудом нашел окно настройки джойстиков, потом опять забыл и искал заново :)
хм. «устройства и принтеры». и ведь логично.
Панель управления там сильно перекроили.
да, первый раз вспоминаешь все сложные идеоматические выражения, которые знаешь. но потом:
Не скажу впрочем, что стало хуже, но непривычно — да.
и оно становится привычным.
0
хм. «устройства и принтеры». и ведь логично.
Там сам джойстик. Окошко «игровые устройства» из старых версий винды еще найти надо) А настройки джойстика только оттуда доступны. Не скажу, чтобы оно в совсем уж нелогичном месте было, но если в новые места панели управления можно попасть по ссылкам из десятка мест, то в это окно — кажись только из контекстного меню джойстика в «устройствах».
+1
но ведь тоже логично, согласись. настройки конкретного джойстика. где им еще быть, кроме как на одной из вкладок?..
0
Э нет) Вылазит окошко со списком джойстиков, откуда уже можно открыть настройки нужного — предварительно выбрав его в списке :)
0
у тебя 100500 джойстиков??! =0
0
у меня только один вопрос: анахера?
0
«Да, мне нравятся клюшки Хораса. Поэтому у меня их уже пять.»
0
Нет. Но если убрать все нули, то будет довольно близко к реальности. Хотя и занижено, пожалуй.
0
фотку. Фотку! ФОТКУ! Ф-ООО-ТТ-КУУУ!!!
0
только вопрос остается прежним: анах столько?
0
Довольно старая. Их уже больше.

только вопрос остается прежним: анах столько?
Повторить цитату про клюшки Хораса?)
0
Довольно старая. Их уже больше.
А, и здесь только пады. Хотя именно они мне больше всего и нравятся.
0
ну, ведь они не все у тебя одновременно подключены?
Повторить цитату про клюшки Хораса?)
этот хорас:
При жизни Хорас Маккой, американский журналист, писатель и киносценарист, большую славу снискал себе не в Америке, а в Европе, где его признавали одним из классиков американской литературы, наравне с Хемингуэем и Фолкнером. Маккоя здесь оценили сразу же по выходу его первого романа «Загнанных лошадей пристреливают, не правда ли?», обнаружив близость его творчества идеям писателей-экзистенциалистов.
или как его гуглить?
0
Не нагуглишь ты его. Это персонаж из какой-то детской передачи вроде улицы сезам, казавшейся мне идиотизмом еще тогда, в детстве.
ну, ведь они не все у тебя одновременно подключены?
Нет. Но предлагать выбор из одного джойстика (тем более когда я его уже выбрал) — еще больший идиотизм) Лучше бы оставили «Игровые устройства» в панели. Впрочем, бывают случаи когда воткнуты 2-3 или один представляется двумя.
0
угу. это мне про извраты представления в системе рассказывать будешь:

и это все одна клава.
(ой, один корневой случайно попал в выделение...)
0
Да не, там как раз без извратов. Двумя, например, представляется адаптер PlayStation->USB, имеющий две дырки для PS-джоев.
0
дык, а как иначе? два джоя, два девайса. меньше никак. при всем желании.
0
Весело, когда джой один, а девайса два. Приходится искать который из них подключен.
0
ну, тут просто реализация не продумана.
0
В семерке WU вменяемый и наконец-то стал похож именно на апдейтер, а не нечто неуправляемое и работающее (а чаще не работающее) по своим неведомым законам. Впрочем, затупить на полчаса при выключении может и он. Время в основном зависит от количества и сурьезности обновлений.
0
признаться (поковырявшись в памяти), об автоапдейтере хрюши имею весьма смутное представление. т.к. на ней ставил апдейты только руками (угу. и качал тоже выборочно). а вот на семерке расслабился. т.к. и подлянок меньше стало (единственное что помню, это KB971033), и не сильно отвлекают.
0
единственное что помню, это KB971033
Эт который крек ломает?) Ну этот-то меня не пугает, семерка у меня лицушная)
Я довольно долго тоже на хрюше обновления не ставил, но теперь решил что лучше ставить. Проблем особых не замечаю пока.
0
Эт который крек ломает?)
именно.
Ну этот-то меня не пугает, семерка у меня лицушная)
меня тоже. всего-то снести его… ;)
я давно уже все ближние компы перевел на автоматическую тихую утановку. пока жалоб не было…
0
ну, спорно. и очень.
я однажды, когда потерял винт с инсталляторами (в том числе и очень редкими), примерно 90% собрал по друзьям/знакомым, с которыми делился.
0
Ценные файлы нужно держать как минимум в двух местах.
0
угу. только понимае этого приходит постфактум.
0
Чем это отличается от клауда, кроме того, что это приходится делать руками с риском забыть/ошибиться?
0
Тем, что эти ваши клауды сегодня есть, а завтра — нету, не говоря уж о последней миле, которая между мной и ними.
0
Тем, что эти ваши клауды сегодня есть, а завтра — нету,
Ценные файлы нужно держать как минимум в двух местах.
в двух разных облаках. проблем-то?
не говоря уж о последней миле, которая между мной и ними.
последняя миля вполне решаема заходом к товарищу, который у другого прова сидит. да хоть даже в инет-кафешку.
0
или в макдональдс. у нас, по крайней мере, инет там бесплатный.
0
ну да. ща почти в каждой забегаловке фришная вафля.
0
Но нет, это не модно — только клауд.
Мода тут ни при чем. Это реально удобно. И при разумном использовании это единственный способ быстро собрать максимально широкую базу и поддерживать ее в актуальном состоянии. Вики вполне может служить примером. А после набирания системой определенной популярности производители сами понесут туда свои доки и описания.
0
Ну вот я и привёл гугловский аппстор — помойка помойкой, база-то широкая, только тем лишь сложнее найти полезные крупицы.
0
Есть и другие примеры. Тот же гитхаб или сорсфорж.
0
Не в тему. Там у каждого участника (ну или у плотно связанного коллектива) свой уютненький подраздельчик, который он модерирует и за которым следит, мы же говорим про чисто коллективное наполнение.
0
Не в тему.
Вы прекрасно понимаете, что в тему и что вопрос больше в выборе политики принятия решения, а не в принципиальной неработоспособности такого подхода.
0
А не правильнее примкнуть к тому же Kicad и совершенствовать его, чем Намереваться создать очередное «что-то», сырое и кривое…
0
1. Достало то, что программы для моделирования схем являются платными.
хм. вложите пару-тройку человеко-лет и сделайте бесплатной. ОЙ! вы кушать ВСЕ эти три года хотите? так простите, эти ваши желания ДОСТАЛИ УЖЕ!!!
:)))
0
Для моделирования есть QUCS :)
0
К сожалению (или к счастью), не осилил все комменты. Но автор хочет изобрести очередной велосипед. Помог бы лучше развивающимся опенсурс-проектам (да хоть те же KiCad, QUCS, geda etc), а не насиловал свой и наш мозг очередным вбросом говна на вентилятор и холиваром.
До кучи гуй на C# это как правило WinForms или WPF… --> WinDows only
Хотя… Флаг в руки. Как говорится, ждем ебилдов :-)
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.