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

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

// 
// Дорогой мейнтейнер:
// 
// Когда ты закончишь «оптимизировать» эту подпрограмму
// и поймешь, насколько большой ошибкой было делать это,
// пожалуйста, увеличь счетчик внизу как предупреждение
// для следующего парня:
// 
// total_hours_wasted_here = 42
//

Уже второй год подряд эксперты Positive Technologies принимают участие в крупнейшей восточноазиатской конференции по информационной безопасности Power of Community. В этом году на мероприятии, состоявшемся в Сеуле, были продемонстрированы уязвимости современных систем АСУ ТП (SCADA), управляющих транспортными, промышленными, топливно-энергетическими и многими другими критически важными объектами.

Введение

Диод — двухэлектродный электронный прибор, обладает различной проводимостью в зависимости от направления электрического тока. Электрод диода, подключённый к положительному полюсу источника тока, когда диод открыт (то есть имеет маленькое сопротивление), называют анодом, подключённый к отрицательному полюсу — катодом. (wikipedia)

Все диоды можно разделить на две большие группы: полупроводниковые и неполупроводниковые. Здесь я буду рассматривать только первую из них.

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

Ответ на статью.

Если вы не разрабатываете ПО для машин или систем автоматического поддержания жизни и тд — нижесказанное работает для вас при грамотном применении.

Сразу скажу — не моя идея, в статье «Проектирования больше нет?» сам Мартин Фаулер писал об эволюционном рефакторинге. А Боб Мартин даже целую книгу запилил с примером поэтапного развития приложения (и не одним), назвав «Быстрая разработка ПО» и продемонстрировав умение виртуозно материться на Java и C++.

Во-первых, говнокод на первом этапе обязателен. Причин куча. Раз — вы ничего не знаете о реальных условиях работы приложения, все ваши домыслы фигня. Пока реальный опыт не получен, пока не занесены первые живые данные реальным пользователем — у вас нет обратной связи. Если вы не согласны, почитайте Макконнелла, миф о стабильных требованиях, и получите левелап.

• Вы присоединились к новому стартапу.
• Вы мегаталантливое создание.
• Вы можете работать 60, 70, 80 часов в неделю для достижения результата.
• Вы офигенный разработчик и дизайнер.
• Вы не попадетесь в ловушки, в которые попадались другие.
• Вы убедитесь, что в этот раз все будет по-другому.
• Вы настолько хороши, что правила вам ни к чему.
• Вы в жопе.

Сегодня мы рады представить бета-версию сервиса авторизации TM ID.



Долгое время ТМ поддерживает и развивает несколько тесно связанных между собой IT-ресурсов:

» Habrahabr
» Brainstorage
» Freelansim
» Hantim
» Toster

Для удобства использования сервисов мы создали единый центр авторизации, который позволяет использовать один аккаунт (TM ID) для упомянутых выше проектов.

Софтверные компании, как Microsoft или Google, публикуют миллионы статей для разработчиков с описанием программных интерфейсов, сервисов и платформ. Они вкладывают огромные усилия в создание документации.

В то же время сами разработчики всё меньше читают официальную документацию, а всё чаще получают информацию на профильных сайтах, показало исследование Ninlabs Research. Выяснилось, что около 50% времени разработчики проводят на специализированных сайтах для программистов, в том числе Stack Overflow, а вовсе не на порталах с официальной документацией.

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

Чуть больше четырёх месяцев назад Дженнифер Девальт (Jennifer Dewalt) приняла важное решение — научиться программировать. Хотя у неё не было опыта в этом деле, она никогда не посещала технических спецкурсов в школе, а наоборот — увлекалась только искусствами, но девушка сразу же решительно взялась за дело.

Дженнифер установила правило, что каждый день будет делать по одному веб-сайту, без выходных. При этом каждый веб-сайт должен сопровождаться новой записью в блоге, а весь код выкладываться на Github. Сегодня наступил 115-й день её марафона.

В последнее время тема удалённой работы стала особенно актуальной — достаточно вспомнить этот недавний пост на хабре, выход книги Remote от Джейсона Фрайда и приуроченный к запуску книги старт биржи поиска удалённых сотрудников от 37 Signals.
Сторонников у неё более чем достаточно, особенно среди работников, уставших изо дня в день добираться до офиса по сумасшедшим городским пробкам. Противников также немало и в первую очередь среди работодателей. Здесь я постараюсь объяснить, почему, несмотря на все минусы (многие из которых, к слову, либо временные, либо вымышленные), удалённая работа — это наше будущее, и будущее весьма близкое. Как человек из IT-индустрии, я конечно имею в виду в первую очередь её, но значительная часть этих наблюдений носит универсальный характер.
Сразу оговорюсь, я не хочу сказать, что работа в офисе уйдёт в небытие, она лишь превратится из единственного возможного способа в инструмент, решающий определённый спектр задач. Под катом список основных плюсов удалёнки для работника и работодателя, а в следующей части я постараюсь опровергнуть основные мифы, к которым часто апеллируют её противники.

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

А начиналось все так: понадобилось мне для одного проекта сделать UI, где надо последовательность обработки сообщений редактировать. Что-то наподобии Simulink'а. Соответственно, полез искать готовые либы/фреймворки. Поначалу подумал, что задачка популярная и кто-нибудь уже сделал это велосипед, поискал, поискал и… не нашел. Точнее нашел много антикварных велосипедов, но кто же будет пользоваться чужим старым велосипедом, если можно сделать свой новый. Но раз уж делать новый велосипед, почему бы не сделать его универсальным, мало ли, где еще пригодится.

Так что попробую в нескольких статья описать процесс разработки с нуля до работающего примера. Ну и чтобы было интересно, а ферймворк был универсален, первая задача для него будет не подобие Simulink'а, а софтина для рисования блок-схем а-ля Visio, но со своим блек-джеком и остальными участниками:)

Часть 1: Учимся рисовать
Часть 2: Обработка событий мыши
Часть 3: Продолжаем добавлять фичи + обработка клавиатуры
Часть 4: Реализуем Drag&Drop
Часть 5: Соединяем ноды

Кому интересно, добро пожаловать под кат…

Сегодня на глаза попался старый вопрос "Почему работодатель предпочитает нанимать веб-разработчика в офис?": habrahabr.ru/qa/22292. Вопрос был задан еще в 2012 году, но, на мой взгляд, ситуация с тех пор не сильно изменилась.

Коллеги, тут есть серьезное недопонимание, которое давно пора устранить.

Многие, как мне кажется, представляют себе фрилансера примерно так:

• Приходит на какую-то отдельную небольшую задачу, выполняет ее и уходит.
• Работает над несколькими мелкими проектами одновременно. Либо имеет постоянную работу, а фрилансером просто подрабатывает в оставшееся время.
• Его не беспокоит проект в целом. Только то, за что он отвечает.
• Огораживает себя техническими заданиями. И из-за каждой новой плюшки может возникнуть конфликт.
• Работает когда хочет. С ним сложно связаться.

Недавно Google объявил, что он переходит от поиска по ключевым словам к полностью семантическому поиску. Не знаю, насколько круты алгоритмы поиска у мировых гигантов, но поиск в маленькой песочнице получается довольно семантическим. Конечно, с поиском по более менее крупным объёмам данных уже не всё так радужно, готовить слова надо очень тщательно, но тем не менее.

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

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

В экспоцентре с 5 по 8 число проходила выставка Interlight Moscow, посвященная разнообразным устройствам питания, соединения, освещения и прочей электроники. К сожалению, я смог туда попасть только к концу ее последнего рабочего дня, и поэтому успел захватить совсем чуть-чуть, китайцев и пообщаться с директором ноотехники о их новинках.


А вот AlexeyNadezhin ее обошел всю, так что будет полезным почитать и его.
Кстати, заглавную фотку я упер у него.

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

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

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

Друзья.

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

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

Итак: Чем бы вы стали заниматься, если бы вам сегодня сказали, что вы больше никогда не можете заниматься тем, чем занимаетесь сейчас? Изначально этот вопрос был про программирование, но поскольку аудитория хабра гораздо шире, я решил обобщить.

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

Исторически сложилось, что существенная часть российских (и exСССР в целом) программистов работают в офшорном программировании. Почему так получилось вполне понятно — в 90-х местные компании, пишущие свои коммерческие продукты можно было пересчитать чуть ли не по пальцам руки.

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

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

Небольшая предыстория:
Однажды я по своей косорукости и несдержанности душевной поцарапал экран монитора своего соседа по комнате в общаге. Макс, ты не мог себе купить монитор с DVI-выходом?!!! Эх… ладно.



В общем, таким образом у меня появился ASUS VW193D-B. Царапина была небольшая, пользоваться практически не мешала. Прошло пару лет, я купил себе монитор большей диагонали, а этот ушел на шкаф на заслуженный отпуск, т.к. продать его за сколько-нибудь значимые деньги уже нереально. Ну и лишний монитор всегда может пригодиться в хозяйстве.

Когда-то я прочитал статью хабраюзера WingedBoar, где он описал свой опыт снятия антибликового покрытия с монитора. habrahabr.ru/post/146644
Я еще тогда этим заинтересовался, но не решился. Боялся испортить монитор. Как оказалось, ничего сверхъестественного в этом нет.

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