Дата на обновяване:02.05.2013

   ПЧЕЛАР / ЕЛЕКТРОНЧИК - пробвай-сам.bg

     Страница за пчеларство, пчеларски и ел.  разработки, представени като статии

Комютърът на пчелина | Нестандартни кошери | Пчеларски сайтове | Пчеларски инвентар | Размисли и идеи за пчеларството Физиотерапия, Апитерапия, Фитотерапия | Книги, Списания, РС, Интернет |  Пчеларски технологии |  Видове мед  | Пчеларски хумор

Сезонни и месечни задължения на пчеларя | Пчеларски статии на руски език | Малки Oбяви свързани с пчеларството

Информация, която е полезна за начинаещия пчелар | Използване на автомобила ... не само за предвижване - видеоклипове

 

 

 
Информация  от  ОБЛАСТЕН  ПЧЕЛАРСКИ  СЪЮЗ  - ПЛЕВЕН

 

 

Полезна и забавна информация за начинаещи с ел., радио и електронен характер, част от която с приложение и в пчеларството

- Електронни схеми, радиосхеми и устройства удобни за повторение от начинаещи;

- Снимки на фигурки изработени от електрически, разноцветни кабели. Други ел. снимки;

- Детски любителски набори - радиоконструктори за сглобяване на радиоприемници наричани играчки;

- Детекторни радиоприемници, техни модели;

- Сувенирни радиоприемници - играчки, някои от тях предназначени за ученици;

- Модулни набори - радиоконструктори от типа "Електронни кубчета" или "Мозайка" с които се работи без поялник и се захранват с батерии;

Информация за електрически и електронни компоненти и устройства, някои от които приложими и в пчеларството

- Токозахранващи устройства. Стабилизатори, преобразуватели, удвоители на напрежение;

- Импулсни стабилизатори на напрежение. Инвертори на напрежение;

- Устройства за дозареждане и компенсиране на саморазряда на акумулаторни батерии;

- Релета за време. Процедурни часовници. Схеми с ИСх 555;

- Цветомузикални устройства. Светлинни ефекти;

- Схеми за регулиране и поддържане на температура;

- Измерване на топлинния режим на радиоелектронна апаратура. Електронни термометри;

- Мрежови трансформатори. Опростени методики за изчисляването им. Електрожен;

- Зарядни устройства за Ni-Cd акумулатори;

- Устройства за имитиране гласовете на животни и птици. Мелодични звънци;

- Уреди, пробници, индикатори, генератори, тестери, измервателни приставки за любителската лаборатория;

- Металотърсачи, включително такива за откриване на метални предмети и кабели;

- Схеми на устройства, приложими за и около автомобила;

- Схеми на устройства с приложение на оптрони;

- Измерване на относителна влажност. Прецизен влагорегулатор. Поддържане на влажността на въздуха;

- Регулатори и сигнализатори за ниво на течност;

- Регулатори на мощност и на обороти;

- Опростено изчисляване на повърхността на радиатори за полупроводникови елементи;

- Схеми за управление на стъпков двигател, включително четирифазен. Енкодер/Валкодер, някои от които реализирани със стъпков двигател;

- Мощни, широколентови, операционни усилватели. Логаритмичен и антилогаритмичен усилвател;

- Електронни реле - регулатори. Реле - регулатор за лек автомобил. Стенд за проверка на реле - регулатори;

- Променливотоков регулатор. Стабилизатор за променлив ток. Ферорезонансен стабилизатор;

- Електронни схеми и устройства приложими в медицината;

- Няколко светодиодни индикатора. Икономичен светодиод. Светодиодна стрелка;

Практически приложими ел. устройства с учебна цел, реализирани с PIC16F84A, PIC16F88, PIC16F628 ... Arduino и др.

Подобряване със свои ръце възпроизвеждането на звука в дома, офиса, автомобила - subwoofer и други варианти

Радиоелектронни сайтове | Електронни библиотеки

 

 Разработки     Главна (съдържание на статиите)                         
Собствено Търсене

 

 



 

Я презираю Arduino из песочницы (Аз се отнасям към Arduino с презрение още от времето, когато като малък си играех в пясъка)


Программинг микроконтроллеров*, Arduino
Я – выпускник специальности «Микроэлектроника и полупроводниковые устройства». За годы обучения я разработал множество устройств на микроконтроллерах, участвовал в конкурсах вместе со своей командой и являлся заведующим лабораторией встраиваемых систем. У меня есть мечта – создать в своей стране условия для разработки роботизированных систем и есть план её достижения, одним из пунктов которого является участие в подготовке большого количества профессионалов в этой области.
 



Я радуюсь, когда будущие инженеры создают свои устройства и расстраиваюсь, когда слышу, как кто-то говорит об использовании Arduino в них.

Это не первая моя статья на эту тему: у меня возникает желание написать такую сразу после прочтения фразы о безграничных возможностях платформы в DIY-топике на Хабре. У меня возникает желание написать об истинной цене деталей после прочтения статьи о покупке конструктора за $200 почти ничего не содержащего (уж простите, запамятовал где видел).


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

Благодаря Arduino увидело свет множество проектов, которые пылились в банках памяти мозга их авторов.

Честно признаюсь, я иногда и сам пользовался кодом, написанным для Ардуино (к примеру, фирма InvenSense производит модуль MPU6050, запустить нормально который получилось только у Jeff Rowberg).
Презираю я тех людей, которые, открыв для себя мир микроконтроллеров, не потрудились осмотреться в нём и тех, кто нагло наживается на подобных людях.

К нам в лабораторию заходил (и работал с нами) студент кафедры информационных технологий — поклонник Arduino. Человек тратил огромные деньги на покупку самих *дуин и модулей к ним. Я не без сожаления наблюдал, как будущий (я всё же надеюсь) создатель роботизированных систем не мог запустить ШИМ нужной частоты, хотя «лётных» часов работы с платформой он намотал немало.
Так вот, этот студент показал мне «измеритель уровня заряда батареи», или как-то так. Я специально нашёл его сейчас на ebay, где он называется «High Sensitivity Voltage Sensor Module -Arduino Compatible» и продаётся за $8.58. Вот он, на рисунке:


Кстати, центральный провод, который «+» — он просто висит в воздухе – всё сделано для максимального удобного подключения простого делителя напряжения, красная цена которому 2 цента за резисторы и 20 центов за разьём – это если в розницу покупать.

Это не единственный случай обмана нашего брата, ниже я приведу ещё несколько. Сейчас же, для любителей структурирования, я напишу основные недостатки Arduino.
1. Библиотеки. Я люблю библиотеки – я пишу свои классы и функции, или использую грамотно написанный код моих коллег – это существенно ускоряет мою работу. Библиотеки Arduino просты в освоении, но на этом их плюсы заканчиваются. К примеру, вы можете всю жизнь формировать задержки с помощью delay-функций и не иметь простейшего представления, как работает таймер на микроконтроллере — из таких минусов состоят все библиотеки Arduino.
Я имею в виду то, что таймер и другая периферия в микроконтроллере реализована так, чтоб компенсировать его однопоточность прерываниями. А люди тратят процессорное время на декрементацию неиспользуемой переменной.
Деление и использование чисел с плавающей точкой на восьмибитных контроллерах AVR – это то, к чему надо прибегать только в самых крайних случаях, когда без этого обойтись никак нельзя.
Строка в последовательный порт не посылается с помощью конечного автомата с множеством пустых циклов ожидания флага опустошения буфера в основном теле программы – это опять же пустое расходование ресурсов – ведь есть прерывания.
Да, в Arduino можно включить прерывания, но кто это делает?
На Хабре есть хорошая статья о том, как ускорить работу библиотек Arduino. Меня она, если честно, поразила тем, что даже работники оборонной промышленности скатились до работы с платформой, но дать общие понятия о скорости работы этих библиотек она может.
2. Среда разработки. Микроконтроллеры можно программировать в IAR, Eclipse, Keil и других, менее известных средах.


А IDE Arduino является кроссплатформенным и с подсветкой синтаксиса.


1. Мощность. Причём, как аппаратная, так и рассеиваемая. Разработка любой встраиваемой системы начинается с выбора компонентов в зависимости от требуемых функций. Для моргания диодом Atmega328 (или 2560) – слишком мощно, а для создания системы реального времени с алгоритмами обработки изображений – слишком слабо.
2. Расхолаживание программистов. Программирование микроконтроллера не требует особых навыков и умений, но потратить пару часов и изучить работу нескольких периферийных устройств, тем самым размяв свои мозги, всё же придётся. Зачем это делать, если можно написать что-то вроде analogRead и digitalWrite?
3. Цена. Тут уже вопрос не только к производителям Arduino и клонов: цены на контроллеры AVR в целом завышены. К примеру, Atmega2560 обойдётся вам в $10. За такие же деньги можно купить два STM32F103. Так получилось потому – что людям лень учить другие контроллеры, а по этим кругом множество материалов и примеров.


На Hobbyking, где любителей различных моделизмов обманывают так-же как и в других магазинах любителей ардуино, продавался как-то обычный конденсатор, под видом какого-то фильтра. Не смог его сейчас уже найти. С трёхпиновым разьёмом, естественно. Всего за 3 доллара.

Arduino Compatible Mini Motor Speed counter Sensor AVR PIC – заменяется светодиодом и фототранзистором, подключающимися к центральному контроллеру и двадцатью строчками кода. Он не стоит 7.98.

2*4 Matrix Keyboard Push Buttons AVR ARM Arduino Compatible – это просто кнопки, которые можно купить по цене 10 штук за доллар.

Есть один девайс в мире, который я ненавижу больше чем Arduino – это mbed. Его разработчики взяли контроллер LPC1768 (есть ещё на LPC11U24), припаяли его на плату с двумя стабилизаторами (о качестве разводки платы я говорить не буду), вывели половину ног наружу (вторая половина никуда не подключена, что очень раздражает), написали онлайн недо-IDE (впрочем, чуть лучше, чем у Arduino, хоть и требует подключения к интернету) и продают его за $64. Простите, но это уже совсем.

Что делать, если вы, вдруг, решили перестать топтаться на месте, и начать изучать микроконтроллеры?
1. На Хабре был цикл статей «STM32F1xx — лечимся от ардуинозависимости вместе» — статьи хорошие и достаточно понятные, жаль, что автор забросил написание новых статей.
2. Всех новичков посылают на easyelectronics.ru, где товарищ DIHALT публиковал учебный курс по микроконтроллерам AVR.
3. «Проектирование приложений на микроконтроллерах семейства 68HC12/HCS12 с применением языка С» С. Ф. Баррет, Д. Дж. Пак – супер книга, помогает понять основы программирования на C для микроконтроллеров. Единственная проблема – вы вряд ли достанете микроконтроллеры Freescale, поэтому примеры придётся самостоятельно портировать примеры на AVR, PIC, MSP430 или любой другой контроллер.
4. Перед покупкой чего бы то не было для своих устройств, почитайте об этом хотя-бы в Википедии — возможно эту же деталь можно купить дешевле, если назвать её по-другому.

Вообще знаете, что странно? Среди пользователей Arduino есть даже те, кто презирают Apple за их «направленность на недалёкого занятого-для-таких-мелочей юзера».

Я не хочу никого обидеть или переубедить. Но я буду рад, если хоть один человек, дочитавший статью до этого момента, поменяет Arduino на простой микроконтроллер – может быть, из него получится хороший разработчик встраиваемых систем в будущем.

комментарии (513)
Я не хочу становится разработчиком встраиваемых систем. У меня есть прекрасная работа и прекрасная область, на которой я специализируюсь и которая приносит мне очень неплохой доход.

А с микроконтроллером я хочу просто поиграться. Не заморачиваясь излишней пайкой, изучением периферии и прочим. И я готов переплачивать за простоту и отсутствие геммороя.
+53
mdcool, 25 июня 2012 в 17:35 #


Кажется, автор имел в виду не тех, кому хочется поиграться, а тех, для кого это специальность и хлеб.
+14
VolCh, 25 июня 2012 в 17:40 #


Кажется, что не тех.
+34
EGlaz, 25 июня 2012 в 17:41 #


Не представляю, для кого ардуино является специальностью и хлебом, кроме его продавцов :)
+2
medik88, 25 июня 2012 в 18:27 #


вы видимо не видели готовые продукты на аурдуйнях. Например автомат, торгующий прохладительными напитками. А если такие изделия существуют, то надо полагать, что их разработчики крайне мало понимают в электронике. Отсюда можно делать выводы о качестве конечных продуктов.
Еще был случай, контора попросила разработать одно устройство. По сути очень простецкое с аппаратной точки зрения. Себестоимость конечного железа была около 300 рублей вместе с печаткой и сборкой. До меня его там разрабатывал ардуинщик. Мини серию в 50 штук он собирался сделать на ардуйне256 + шилд. Естественно цена там была аховая. Работодатель в этом плохо соображал, думал что такие модные веяния в мире электронике, что все это круто и супер надежно. Потом его друг узнал об этом и раскрыл глаза, вообщем вовремя спохватились. И супер модный код я тоже видел, немного смеялся.

 

В таких случаях три фактора часто действуют (по одному или в сочетаниях):
— заказчик не компетентен
— заказчик не готов платить за работу квалифицированны специалистов «почему-то» отя щи больше денег чем любители по-сути.
— таки специалистов просто не хватает на всех заказчиков
Про коррупцию и т. п. умолчим. И такая ситуация далеко не только на рынке разработки софта или девайсов, но и, например, на строительном, несмотря на то, что подлежит обязательному лицензированию деятельность на нём.
+21
eaa, 25 июня 2012 в 18:46 #


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

Так что бывает дешевле заплатить за менее красивое творение, но которое потребует намного более дешевой поддержки.
+1
yul, 25 июня 2012 в 20:22 #


Вполне можно на ардуино сделать прототип или тестовую партию для проверки перспективности девайса. А заказчики, которые хотят то, что на слуху, вместо того, чтобы доверить технические решения профессионалам во всех отраслях водятся.
0
faddistr, 26 июня 2012 в 15:51 #


Под каждый контроллер, производитель продает так называемый отладочный модуль. Использовать андруино рационально, когда вы будет использовать Атмегу входящию в его состав. Но тем не менее все слишком заостряют внимание на мк производства Атмел и не видят аналогов вообще.

+В комплекте с отладочным модулем всегда идет тонна примеров.
0
denisgorbunov, 27 июня 2012 в 15:15 #


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

А вот брать Ардуино для проверки принципов функционирования изделия (грубо говоря — будет ли нормально работать система, если автоматика будет вовремя релюшку переключать), а не для создания полноценного готового прототипа — тогда другое дело. Но тогда и неважно что за микроконтроллер взят будет в дальнейшем.
0
faddistr, 28 июня 2012 в 12:44 #


Программные библиотеки есть и под другие мк. Например под Сygnal(C8051) от компании Силабс есть просто гора примеров и программных библиотек от производителя. Там даже есть Мастер который позволяет вам сгенерить конфигурацию пинов с нужными вам параметрами таймеров, SPI и тд. Также аналогичные мастера есть под все их микросхемы: под езерернет(CP2200), радио и тд. У других производителей мк тоже самое есть, но в меньшем объеме.
А что касается прототипов, то серийный Андруино дороже серийного СТМ32влдисковери, при том что последняя имеет куда как больше возможностей.
0
faddistr, 28 июня 2012 в 12:47 #


т.е. мастер вам код генерит по С++ и ассемблер.

Мало ли кто какие возможности имеет.
Вы забываете 3 фактора:

1. Возможностей нынешних микроконтроллеров даже не самых мощных для огромного пласта задач заглаза. Частенько СТМ32, что АтМега — уже без разницы.
2. Решение с чем работать опытный руководитель принимает с учетом доступной рабочей силы. Скажем, большие заводы в маленьких городах не строят уже давно. Ардруинщиком легко может стать любой толковый человек с формальным мышлением.
3. Наличие готовых, выпускаемых серийно, в давно отлаженными багами плат — существенно ускоряет разработку.
4. Часто, очень и очень часто имеет значение скорость разработки. Очень часто целесообразнее заплатить программисту плюсом те деньги, что будут потрачены на разводку, изготовление и монтаж платы, чтобы он быстрее написал программу. Или проверил ее лишний десяток раз.

Пы.Сы.:
Позвольте засомневаться насчет дешивизны упомянутого СТМ32.
Совсем не обязательно покупать Ардуино оригинал фирменный. Сейчас Ардуино китайцы клепают в промышленных масштабах за совсем разумные деньги.
0
faddistr, 28 июня 2012 в 20:17 #


1. Возможно.
2. Может. Но почему бы не пробывать и другие мк?
3. А с другими мк плат отлаженных плат нет? Не аргумент.
4. У нас(на Украине) дешевле взять стм32(20$) или Лаунчпад от ТИ(10$). Я не видел дешевых Андруин(в среднем от 30$). Возможно у вас другие ценовые расценки. Так что тоже возможно.
П.С.
А теперь подумаем сколько стоит напечатать плату:
К слову цена печати плат одной промышленной заготовки(300 на 400 мм)~10$(на заготовки размещается может как комплект из разных плат, так и одинаковые платы, цена с учетом распилки плат) Подготовка производства(изготовление шаблонов и тд)~40$.(цены Киевского завода Радар). Т.е. 40 платим один раз и 10 за каждый лист. Распайка-не знаю, но есть
фирмы предоставляющие такие услуги. Такие услуги предоставляются как фирмам так и частным лицам. У китайцев еще дешевле. Разумеется еще комплектующие и тд, но обычно дешевле изготовить платы под свои нужды. Да и изделие лучше выглядит. Возможно вам действительно дешевле использовать Андруино, но у нас дешевле к нему вообще не прикасаться. Конечно будет еще этап исправления ошибок, но изделие будет качественней.
0
denisgorbunov, 28 июня 2012 в 14:56 #


Вы серьезно считаете, что никто не знает про наличие программных библиотек на различных МК?

Я совсем про другое.

Разработка полноценного прототипа на Ардруино и потом его перенос на другую платформу — может оказаться слишком накладен по причине того, что библиотеки другие на другой платформе.
+13
kekekeks, 25 июня 2012 в 20:49 #


Ну и чёрт бы с ним, с торговым автоматом. Там разница в цене железки в 50 баксов роли не играет ни малейшей, зато для программирования ардуин и последующей поддержки кода можно задействовать более доступную рабочую силу. Это 21-ый век, когда время живых людей стоит намного дороже бездушного железа.
+21
EGlaz, 25 июня 2012 в 21:33 #


21й век: от говнокода и говносайтов переходим к говноэлектронике, дальше обратно к говномеханике… продуктам питания и т.п. Главное, чтобы самолёты не делали на таких игрушках и через 15 фреймворков…

PS: минусуйте — я готов :)
говноэлектронике
И в чём же она говно? В том, что неоптимально расходует вычислительные ресурсы? Но позвольте, код-то при этом сам по себе проще. Да, он медлителен, но он понятен, его легко читать и поддерживать. В конце концов в синхронном коде намного сложнее сделать ошибку. В итоге получаем ситуацию, когда не нужно знать особенности железа, достаточно сосредоточиться на бизнес-логике. Сейчас никто не пишет офисные пакеты на ассемблере, сейчас это приходит и на микроконтроллеры, ресурсы которых уже позволяют использовать тот же подход, что и для ПК.
Резюмируя: мы получаем надёжность за счёт избыточности ресурсов. Если мне не изменяет память, в военных и используемых в опасных отраслях системах так делали всегда.
Я понимаю вашу страсть к «байтоёбству», но в реальной жизни сейчас оно зачастую не просто не нужно, но и вредно.
–6
woddy, 25 июня 2012 в 21:42 #


Не в избыточности дело. Используя чужой код получаешь запас чужих граблей/ошибок. Но для мелких домашних поделок это не имеет значения.
+7
kekekeks, 25 июня 2012 в 21:47 #


Используя чужой код получаешь запас чужих граблей/ошибок.
Т. е. вы предлагаете для, ну, скажем, текстового редактора с нуля писать прошивку BIOS, ядро ОС, библиотеки прикладного уровня и всё такое?
+1
woddy, 25 июня 2012 в 21:51 #


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

Обычно достаточно взять адекватные проверенные временем библиотеки, а не наколеночное студенческое поделие, позавчера выложенное в интернете. Как правило, стандартные библиотеки от производителя устройства достаточно надёжны.
–2
andrewsh, 25 июня 2012 в 22:34 #


Их как правило нет. Точнее, то, что есть — это очень тонкая базовая прослойка. BIOS и близко не валялся, да.
+13
JC_Piligrim, 25 июня 2012 в 22:52 #


То есть ваш пилотный набор велосипедов для парового котла окажется абсолютно безошибочным с первого раза,

в то время, когда

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

:)
+1
woddy, 25 июня 2012 в 22:54 #


это зависит от уровня/квалификации разработчика ;)

микроконтроллеры это не линукс, там сложно найти нормальные проверенные либы.
0
woddy, 25 июня 2012 в 22:57 #


использовал готовые либы под ту же ардуину и то приходилось исправлять баги и подпирать костылями. т.к. без них код просто не работал в ряде случаев.
не знаю какие там еще есть ошибки которых я не заметил, но т.к. я делаю «для
домашнего применения» меня это мало беспокоит.
0
eaa, 26 июня 2012 в 10:54 #


Вот я бы сделал как раз с точностью до наоборот — поиграть в переписывание либ под люстру еще куда ни шло, а вот с нуля на свои грабли наступать с паровым котлом поостерегся бы. Да, не брал бы первое, что под руку попадет, поискал бы качественные решения, но с нуля писать точно бы не стал — уже не раз проходили, что каждый вновь приходящий «крутой» разработчик горит желанием переписать все «правильно» и с нуля.
–1
Nepherhotep, 26 июня 2012 в 13:10 #


Все-равно библиотека библиотеке рознь. Когда андроид только появился, появилось куча глючных библиотек. Часть их было просто портировано под дэлвик, а часть написана с нуля. В итоге часто было надежней написать с нуля свой собственный (пусть и облегченный) вариант. Я имею ввиду библиотеки по сложности, как ORM.
Вообще написание с нуля не такая уже и плохая практика, если знаешь, что именно нужно, т.к. готовые библиотеки — это часто 90% ненужного функционала.
+1
VgaCich, 26 июня 2012 в 13:16 #


Ну для свеженаписанных/свежепортированных библиотек это нормально. Но свой велосипед тоже будет свеженаписанным. Кроме того, широкоиспользуемые библиотеки обычно выправляются быстрее — большая база пользователей эффективнее выявляет баги. Своей же на пользу может пойти только то, что в ней нет ненужного функционала и несомых им багов, да то, что она досконально понятна, что облегчает отладку.
+1
EGlaz, 25 июня 2012 в 22:03 #


Я предлагаю для текстового редактора писать код непосредственно под ОС, а не под какую-то виртуальную машину, развёрнутую на виртуальном сервере, с базой данных, веб клиентом… чтобы в результате на экране увидеть такой же редактор, только тормозящий на ровном месте.
домашнего применения» меня это мало беспокоит.
0
eaa, 26 июня 2012 в 10:54 #


Вот я бы сделал как раз с точностью до наоборот — поиграть в переписывание либ под люстру еще куда ни шло, а вот с нуля на свои грабли наступать с паровым котлом поостерегся бы. Да, не брал бы первое, что под руку попадет, поискал бы качественные решения, но с нуля писать точно бы не стал — уже не раз проходили, что каждый вновь приходящий «крутой» разработчик горит желанием переписать все «правильно» и с нуля.
–1
Nepherhotep, 26 июня 2012 в 13:10 #


Все-равно библиотека библиотеке рознь. Когда андроид только появился, появилось куча глючных библиотек. Часть их было просто портировано под дэлвик, а часть написана с нуля. В итоге часто было надежней написать с нуля свой собственный (пусть и облегченный) вариант. Я имею ввиду библиотеки по сложности, как ORM.
Вообще написание с нуля не такая уже и плохая практика, если знаешь, что именно нужно, т.к. готовые библиотеки — это часто 90% ненужного функционала.
+1
VgaCich, 26 июня 2012 в 13:16 #


Ну для свеженаписанных/свежепортированных библиотек это нормально. Но свой велосипед тоже будет свеженаписанным. Кроме того, широкоиспользуемые библиотеки обычно выправляются быстрее — большая база пользователей эффективнее выявляет баги. Своей же на пользу может пойти только то, что в ней нет ненужного функционала и несомых им багов, да то, что она досконально понятна, что облегчает отладку.
+1
EGlaz, 25 июня 2012 в 22:03 #


Я предлагаю для текстового редактора писать код непосредственно под ОС, а не под какую-то виртуальную машину, развёрнутую на виртуальном сервере, с базой данных, веб клиентом… чтобы в результате на экране увидеть такой же редактор, только тормозящий на ровном месте.

Окей, тратьте на это пару лет жизни, я склепаю за пару дней, пользователь будет доволен, ведь его задачи решаются уже сейчас, а не когда кто-то допилит свою дорогую, сложную и непереносимую на другое железо систему, которая к моменту выпуска уже год как морально устарела.
0
EGlaz, 25 июня 2012 в 23:27 #


А вы уверены, что каждому пользователю нужно тормозное, но переносимое на другое железо ПО? Каждый ежедневно запускает один и тот же текстовый редактор под виндой, на айфоне, на айпаде, в линуксе...?

Лучше написать хорошо под одну систему, чем плохо, но под все. Хотя я смотрю современные программисты думают иначе :)
+7
kekekeks, 25 июня 2012 в 23:28 #


Я верю в то, что решение, работающее сейчас, лучше решения, которое заработает через год. Этим всё сказано.
+3
EGlaz, 25 июня 2012 в 23:37 #


Это ли не девиз говнокода? Лучше сейчас тяп-ляп, чем завтра хорошо?
Если речь о сиюминутных игрушках типа новой версии винлокера, весёлого фермера и т.п. — то да, главное сделать срочно, пока это не сделал твой сосед по лестничной клетке.
Но это всё мелкие ремесленные поделки, не более. Если бы все программисты шли таким путём не было бы ни Quake3, ни AutoCad,… да в общем ничего хорошего бы не было. Были бы одни фриварные однодневки, за которые деньги платить жалко и которые зарабатывают только на рекламе.

facepalm.svg

Сделайте сначала хоть что-то, что уже сейчас, но работает. Ищите боттлнеки, оптимизируйте. Переписывайте совсем уж критичные части на C или даже на асме. В итоге у вас продукт начнёт работать завтра, а через 3 месяца достигнет 90% той производительности, что то сложное мегаоптимизированное поделие, которое вы бы выпустили через год, а потом ещё полгода фиксили баги. А они обязательно будут, поверьте. Только вот вылавливать их в таком коде намного сложнее. Как говорил один из создателей языка C, отладка кода вдвое сложнее, чем его написание, так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.

Так что рекомендую скатать свой перфекционизм в трубочку, отложить куда-нибудь подальше и вернуться к реалиям жизни.
+3
Valery35, 26 июня 2012 в 00:10 #


Где то рядом ходит старый общеизвестный термин «стоимость владения».
В чем то вы оба правы. Просто потому, что представляете конкурирующие подходы. И наилучшее решение — вести параллельно такие разработки с целью сохранения конкурентности (когда это возможно).
То что монопольное использование только одного пути — это тупик, надеюсь, очевидно?
–5
vajadhava, 26 июня 2012 в 11:08 #


> Как говорил один из создателей языка C, отладка кода вдвое сложнее, чем его написание, так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.

Извините, но вы сейчас что-то нескладное сказали, над вами потешаться будут…
+4
kekekeks, 26 июня 2012 в 11:11 #


Я всего лишь процитировал г-на Брайана Кернигана. Если вы вдруг не знаете, кто это, что вы вообще забыли на Хабре?
26 июня 2012 в 11:20 #


Предположил что вы соглашаетесь с этим бредом, как видно по реакции — не ошибся.
+2
Alexeyco, 26 июня 2012 в 10:30 #


По-моему, вам холиваров надо. Вы, вероятно, ничего так и не смогли продать по-настоящему — начиная с переговоров, заканчивая внедрением. Тот девиз, который вы переиначиваете звучит так: лучше сейчас, но чтобы решало задачи, чем с рюшечками и няшечками когда уже совсем будет не нужно.
+1
Mrrl, 26 июня 2012 в 11:06 #


Помню, в середине 90-х разработчики Автокада в течение нескольких лет боролись с какой-то структурой размером в 18 КБ, через которую там шла вся работа. Все понимали, что это плохо, но ничего не могли с ней поделать. Чем это закончилось, не знаю.
+2
EGlaz, 26 июня 2012 в 11:38 #


Это закончилось тем, что Автокад уже лет 10-15 является лидером на рынке 2D «САПРа», именем нарицательным и основоположником стандартов в этом деле.
0
Mrrl, 26 июня 2012 в 13:14 #


Насчет 2D может быть. А так на слуху все больше Cyclone, Pointools, Geomagic, FaroScene, CloudWorx и прочие подобные системы…
+2
EGlaz, 26 июня 2012 в 13:25 #


Когда я был инженером, у меня на слуху для 3D были Компас, T-flex, SolidWorks, Pro-Engineer, Unigraphix, и любимая Catia.
Как быстро всё меняется :)

Это мы со своими сканерами виноваты. Облака по 100-1000 миллионов точек надо чем-то переваривать :) А пользователи обрадовались возможности контроля сборки и reverse engineering — вот им и приходится пользоваться этими системами.
0
Int_13h, 26 июня 2012 в 13:37 #


И при этом жрет ресурсов как лошадь. Нанокад по сравнению с ним, летает при том же функционале :)
0
EGlaz, 26 июня 2012 в 14:42 #


Когда я работал с AutoCad — нанокада не было вообще.
И старые версии ACAD'а летали очень шустро. После примерно 2002 и далее — с каждым годом(!) их стали набивать всякой фигнёй и они становятся всё более неповоротливыми. В те времена я уже перешёл на 3Д и потерял к сабжу интерес.
–6
EGlaz, 25 июня 2012 в 21:47 #


Вот я именно об этом! Любая прослойка, любая интерпретация с языка на язык, с одной виртуальной машины на другую — куча лишних движений, тормоза и растущая в геометрической прогрессии ненадёжность. К глюкам кода (который теперь пишется «легко и быстро») добавляются глюки прослоек.
+1
yuriykulikov, 25 июня 2012 в 22:46 #


Все эти лишние движения неспроста. Например, допустить утечку памяти на Java значительно сложнее чем на С. Виртуальных машин не так уж много, все используют одни и те же машины, следовательно, глюков там мало. Приложения же пишут все кому не лень, соответственно если производительность не так уж критична, то чем больше функционала реализуют стандартные компоненты, тем лучше (например, memory management). «Преждевременная оптимизация — это корень всех бед»(с). Это не говоря об отладке и прочих благах.

Зато допустить утечку открытых файлов — на яве куда проще чем на Си.
Вся эта автоматическая сборка мусора прекрасно стимулирует написание говнокода.
+1
woddy, 26 июня 2012 в 09:36 #


интересно, те кто минусуют этот пост под контроллеры программировали? :D
0
denisgorbunov, 27 июня 2012 в 15:20 #


Библиотеки Ардуино не разовый код. С ним работает огромное количество народа. Скорее наоборот — при обычных лимитах на время разработки в коде написанном одним программистом будет больше ошибок.
Спасает ситуацию только то, что этот программист пишет код под вполне конкретную ситуацию — и код проще.
+1
h0rr0rr_drag0n, 26 июня 2012 в 00:46 #


А скажите пожалуйста, в ситуации, когда заказчиком поставлено ограничение на стоимость оконечного устройства, что не такая уж и редкость, будет ли допустимо для разработчика встраиваемых вычислительных систем «неоптимально расходовать вычислительные ресурсы»?

Может ли разработчик встраиваемых вычислительных систем поручиться, что ему не понадобятся в будущем, в соответствии с изменившимися требованиями заказчика, те самые вычислительные мощности, которые он так не оптимально расходовал?

26 июня 2012 в 00:51 #


будет ли допустимо для разработчика встраиваемых вычислительных систем «неоптимально расходовать вычислительные ресурсы»
Ровно до той поры, пока он вписываетесь в поставленные рамки, очевидно.
соответствии с изменившимися требованиями заказчика, те самые вычислительные мощности, которые он так не оптимально расходовал
Вот когда понадобятся, тогда и будет оптимизировать, содрав с заказчика на это дополнительные средства в связи с изменениями ТЗ.
0
h0rr0rr_drag0n, 26 июня 2012 в 02:13 #


Оптимизация встраиваемой системы может состоять не только в оптимизации программной составляющей. Вполне возможна ситуация, когда оптимизация программы исчерпала свои возможности и разработчикам придется переходить к оптимизации железной составляющей системы, что встает в уже совсем другие задачи, другие сроки и другие деньги…
Не все проблемы возможно решить лишь тратой денег, кое-где возможно придется потратить и свое время, которое могло быть потрачено с куда большей пользой…
+3
kekekeks, 26 июня 2012 в 02:15 #


Не все проблемы возможно решить лишь тратой денег, кое-где возможно придется потратить и свое время
Деньги — это время, выраженное через труд и средства производства.
0
h0rr0rr_drag0n, 26 июня 2012 в 02:26 #


Все же есть некоторая разница между тратой чужих денег и тратой своего времени…

26 июня 2012 в 02:30 #


Не хотите тратить своё время — найдите того, кто будет тратить своё и платите ему зарплату, так вся экономическая система уже много веков работает.
0
h0rr0rr_drag0n, 26 июня 2012 в 12:02 #


Однако мы отошли от темы изначальной дискуссии.
Опять же повторюсь, на мой взгляд, не все проблемы можно решить с помощью денег. Физические законы, например, с помощью денег не поменяешь.
Что мешает изначально делать нормальную систему, в которой предусмотрены возможные и скорее всего неизбежные изменения в будущем?
По крайней мере, не придется тратить свое время, которые могло быть потрачено с куда большей пользой, на куда более развивающие задачи. Причем, вышесказанное верно и для самого разработчика, как и для того, кого наймут.
+2
kekekeks, 26 июня 2012 в 12:04 #


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

26 июня 2012 в 12:28 #


Не все проблемы можно решить, когда они появились на горизонте. Уточню — мы ведь сейчас говорим не о программном коде, а о железе, аппаратуре, на которую неумолимо действуют законы физики, как минимум.
Небольшой пример. Заказчику — транспортной компании, в ведении которой автомобили и самолеты, понадобились некие GPS-маячки, которые она хочет ставить на свои автомобили и может быть в будущем на самолеты. Если мы пойдем по принципу «решаем проблемы, когда они появляются на горизонте», то скорее всего сначала будут созданы автомобильные маячки, которые потом попытаются впихнуть на самолеты — мы ведь решаем проблемы по мере их поступления…
А потом внезапно выяснится, что проще спроектировать отдельные маячки для самолетов, потому что автомобильные не пролезают либо по электромагнитному излучению, либо по устойчивости к вибрациям и перегрузкам и так далее.
Но что интересно, в случае, когда мы предусмотрели «миграцию» наших систем на самолеты, тратится меньше и денег и времени заказчика, чем в разобранном, увы. Небольшая доработка уже существующей системы и разработка новой это две отдельные категории со своими временными и денежными затратами…
0
kekekeks, 26 июня 2012 в 12:31 #


Вы сейчас привели пример проблемы, которая уже маячит на горизонте, а не высосана из пальца. У меня такое впечатление, что либо я как-то непонятно излагаю свои мысли, либо вы не читаете, что я пишу.
0
h0rr0rr_drag0n, 26 июня 2012 в 12:44 #


Возможно мы друг друга недопоняли. Как я вижу, теоретическая возможность того, что GPS-маяки будут в будущем ставиться в самолеты — эта проблема не маячит на горизонте. А вот когда производителю таки по настоящему становятся нужны GPS-маячки в самолетах — вот тогда проблема и появляется на горизонте. ....

Остальные мнения - адрес:http://habrahabr.ru/post/146489/



 

 

Материалите подготви за сайта:

Иван Парашкевов

e-mail: ivanparst@dir.bg

 

         главна страница                   горе

 

 
 
СТАТИСТИКА
    

Copyright2007  Design by