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

Итак, вуаля!


За источник информации была взята статья из вики. В блок-схеме «UTF-16 → CP 866» означает, что исходная кодировка была «UTF-16», а распозналась она как «CP 866».

Как всегда — кликабельно. Исходник в .docx: здесь.

Приятного времени суток!

Сколько человек хочет заняться разработкой под Android, но в силу определенных обстоятельств все никак не может начать (у кого-то нет времени, кому-то скучно просто прорешивать примеры, лень, неопределенность)? Сколько человек добавляет каждую, кажущуюся интересной и полезной, статью на хабре в избранное и забивает? До конкурса ВКонтакте на разработку мессенджера под Android, я был среди числа вышеописанных пользователей. Но в один роковой момент все изменилось…

От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

Три дня и три ночи мастер не появлялся из своей кельи. На четвертый день монахи отправили послушника проведать его.

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

Сейчас уже никто не создает программы в консоли. Используя любимую IDE, разработчик чувствует себя неуютно за чужим компьютером, где её нет.
Решив разобраться в работе Ant и Maven, я поймал себя на том, что не смогу собрать приложение без них в консоли.
В данной статье я постарался уместить все этапы проектирования демонстрационного приложения, чтобы не искать справку по каждой команде на просторах Интернета.

Сегодня, во время утреннего разговора с коллегой о продуктивности работы и «способах входа в поток», мне рассказали о топике на сайте rsdn.ru. Там, в одном из комментариев, рассказывается об университетском эксперименте, который объясняет, когда полезно, а когда вредно слушать музыку на рабочем месте. Всё вроде бы и так понятно, и все об этом давно догадывались, но иметь ещё одно научное обоснование своим догадкам никому не повредит:

«В ответ на жалобы сотрудников по поводу шума можно попытаться вылечить симптомы или же устранить причину. Устранение причины потребует создания заграждений от шума — стен и дверей — и будет стоить денег. Лечить симптом гораздо дешевле. Установив «Мьюзек» или другой источник розового шума, вы малой кровью заглушаете шум, мешающий работе. Можно и ещё больше сэкономить — просто не обращать внимания на проблему; людям тогда придётся прибегнуть к помощи магнитофонов и наушников, чтобы защититься от шума. Избрав один из таких подходов, вы должны быть готовы понести невидимое наказание — пострадают творческие способности ваших сотрудников.

Вступление

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