Я хочу стать архитектором ПО:

Это хорошая цель для разработчика

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

Хм. Ну, тогда ты вовсе не хочешь стать архитектором ПО.

Конечно хочу! Я хочу быть тем человеком, который принимает все важные решения.

Это хорошо, но ты не перечислил важных решений. Ты перечислил решения, не играющие особой роли.

В смысле? База данных – это не важное решение? Знаешь, сколько мы денег тратим на них?

Скорее всего слишком много. И нет, база данных – это не одно из самых важных решений.

Как можно такое говорить? База данных находится в самом центре системы! Там собраны все данные, они сортируются, индексируются и к ним осуществляется доступ. Без нее не будет системы!

База данных это просто устройство ввода-вывода. Так получилось, что она предоставляет некоторые полезные инструменты для сортировки, запросов и отчетов, но все это – вспомогательные аспекты в рамках системной архитектуры.

Привет, %username%! Бывает необходимо генерировать ID не подряд, причем чтобы они гарантированно не повторялись. На youtube это используется для того, чтобы вы не могли брутфорсом получить все новые и старые видосики, так же это не редкость на разных файлообменниках и вообще везде где нужно предотвратить или хотя бы затруднить возможность прямого перебора значений.


К примеру, в системе moodle, которая использовалась у нас в универе для тестирования студентов, ID ответов были инкрементными и сквозными на всю базу. Логично предположить, что правильным ответом был тот, что с наименьшим ID в пределах вопроса. В общем, проблем с тестами у нас не было. Потом они перешли на GUID, но я к тому моменту уже выпустился, хехе.

Давайте рассмотрим несколько способов генерации таких ограниченных по длине последовательностей от самых простых до криптографически стойких.

Большинство людей не умеют адекватно оценивать сроки выполнения задач. Ой как это заставляет порой понервничать… Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.



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

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)

Итак. Если вы не садист или моральный урод, а ваши сотрудники — не мазохисты, то сомневаюсь, что кому-то из вас наказания доставляют удовольствие. Мне — нет.

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

Сразу скажу — топик — для тех, кто не разобрался что такое MapReduce. Для тех, кто разобрался — полезного тут ничего не будет.

Начнем с того как собственно родилась лично у меня идея MapReduce (хотя я и не знал, что он так называется, и, разумеется, пришла она мне куда позже чем Гугловсцам).

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

Как посчитать все слова в Википедии (неправильный подход)

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

В самом простом случае мы можем завести хеш (dict, map, hash, ассоциативный массив, array() в PHP) и считать в нем слова.

$dict['word1'] += 1

Но что делать когда память под хеш кончится, а мы посчитали только одну сотую всех слов?

Для лучшего понимания этого поста, прочитайте сначала предыдущий пост про прокрастинацию.

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

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

Без всякого сомнения в моей голове была Обезьянка Немедленного Удовольствия, но она была милее всех на свете. С постоянно маячащими дедлайнами, Панический Монстр никогда не спал и Обезьянка знала об этом. Она конечно постоянно отвлекала, но не была за главного.

Мой мозг в школе:

Какая-то «не здоровая пьянка» пошла последнее время на хабре про собеседования. Люди, хватит уже, нет ничего страшного и особенного в собеседованиях, я уже несколько лет провожу их с IT-шниками, и в 95% случаев это адекватные и приятные люди. Потому хочу поделиться с вами «дзеном» о том, как лучше проводить именно техническое собеседование, да и вообще оценивать навыки тех. специалистов, так как вопрос оценки компетентности технического специалиста может быть довольно сложным, особенно если вы не хотите проводить собеседование на 3 часа к ряду. С данной моделью вы вполне можете уложить тех. собеседование в 40-50 минут (а то и быстрее) и быть уверенным в решении на 80-90%. Если про оценку эмоционального интеллекта, базовой мотивации и просто уровня адекватности, информации довольно много, то вот про то, как эффективно оценивать технические навыки специалиста, зачастую, «кто в лес, кто по дрова». Данная статья может быть также полезна и тем, кто просто хочет эффективно расти как специалист, потому как именно их знания и рассматриваются.

«Инвесторы и аналитики спрашивали нас о том, что мы запланировали на будущее. Нашим настоящим ответом было бы: «У нас вообще нет планов».»
— Пол Грэм, разработчик, инвестор, эссеист.



Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод спасибо Щекотовой Яне)

Читать первую часть главы.

Подход к делу

Иметь возможность выпускать программу незамедлительно — существенный мотиватор. Часто по пути на работу я думал об изменениях, которые мне хотелось внести в приложение, и вносил их в тот же день. Это также работало и для более крупных фич. Даже если на написание чего-то требовалось две недели (а на некоторых проектах и того больше), я знал, что смогу увидеть результат как только все будет реализовано.

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

Добрый день.
В рамках набора на курс «Multicore programming in Java» я делаю серию переводов классических статей по многопоточности в Java. Всякое изучение многопоточности должно начинаться с введения в модель памяти Java (New JMM), основным источником от авторов модели является «The Java Memory Model» home page, где для старта предлагается ознакомится с JSR 133 (Java Memory Model) FAQ. Вот с перевода этой статьи я и решил начать серию.
Я позволил себе несколько вставок «от себя», которые, по моему мнению, проясняют ситуацию.
Я являюсь специалистом по Java и многопоточности, а не филологом или переводчиком, посему допускаю определенные вольности или переформулировки при переводе. В случае, если Вы предложите лучший вариант — с удовольствием сделаю правку.
Этот статья также подходит в качестве учебного материала к лекции «Лекция #5.2: JMM (volatile, final, synchronized)».

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

Ну и да, приходите учиться ко мне!

---

JSR 133 (Java Memory Model) FAQ

Jeremy Manson и Brian Goetz, февраль 2004

Содержание:
Что такое модель памяти, в конце концов?
Другие языки, такие как C++, имеют модель памяти?
Что такое JSR 133?
Что подразумевается под «переупорядочением» (reordering)?
Что было не так со старой моделью памяти?
Что вы подразумеваете под «некорректно синхронизированы»?
Что делает синхронизация?
Как может случиться, что финальная поля меняют значения?
How do final fields work under the new JMM?
Что делает volatile?
Решила ли новая модель памяти «double-checked locking» проблему?
Что если я пишу виртуальную машину?
Почему я должен беспокоиться?

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

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

Итак…

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



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

В качестве предисловия

Веб-дизайнерский народ в последнее время распробовал single page web applications. Что оправдано во многих случаях.
Но явно ошибочно считать что single page web application не сделать без чего-то типа AngularJS, Ember и прочих Knockouts.
Во всяком случае если вам нужно сделать нечто простое типа To-do списка совершенно не обязательно тащить на клиент килобайты мега-фреймворка. На самом деле килобайты трафика это пол беды. Основная цена, скажем AngularJS, в том что он, как любой универсальный data binding механизм, создает значительную run-time нагрузку.

Эта статья про то как в 60 строках кода + jQuery/Zepto сделать простой app framework котрый можно расширять под свои нужды и без лишних сущностей в нагрузку.

Постановка задачи

Наш framework должен ...:

1. … поддерживать routing, т.е. должна быть возможность сказать в деклартивной модели: «этот вот url hash должен быть показан в этом view».
2. Должна быть возможность динамической загрузки разных view. Какие-то части нашего приложения могут быть либо тяжелы для начальной загрузки, либо не нужны, например, для незалогиненного пользователя.
3. Должна быть возможность динамической загрузки скриптов. По причинам изложенным в п. 2
4. Наше приложение будет поддерживать browsing history — кнопка «назад» в браузере должна показывать предыдущую страницу и т.д.
5. Ну и все это должно быть компактным и расширяемым как того будет требовать логика нашего приложения.

Пример того что мы хотим получить

Приложение Bootstrap'нутый список контактов — содержит сам список, карточку — детали контакта и некую панель управления (dashboard). Что будет на той панели нам не важно — знаем что что-то будет и ладно.

Первый промежуточный релиз Spring Framework 4.0 M1 предоставил поддержку SockJS на стороне сервера — лучшая и наиболее полная альтернативная реализация WebSocket. Вам потребуется этот резервный вариант в браузерах, не поддерживающих WebSocket и в ситуациях когда прокси препятствует их использованию. Проще говоря, SockJS позволяет строить WebSocket-приложения уже сегодня, которые, ко всему прочему, умеют прозрачно переходить на резервные возможности.

Но даже с резервными вариантами проблемы остаются. Сокет — довольно низкоуровневая абстракция и подавляющее большинство веб-приложений сегодня не адаптированы для сокетов. Вот почему протокол WebSocket определяет механизм под-протоколов, который, по существу, позволяет (и поощряет) использование протоколов более высокого уровня над WebSocket, аналогично тому как мы используем HTTP поверх TCP.

Второй промежуточный релиз Spring Framework 4.0 M2 позволяет использовать высокоуровневые протоколы обмена сообщениями поверх WebSocket. Для демонстрации этого, мы разберем пример приложения.

Перевод поста Visualizing Docker Containers and Images, от новичка к новичкам, автор на простых примерах объясняет базовые сущности и процессы в использовании docker.

Если вы не знаете, что такое Docker или не понимаете, как он соотносится с виртуальными машинами или с инструментами configuration management, то этот пост может показаться немного сложным.

Пост предназначен для тех, кто пытается освоить docker cli, понять, чем отличается контейнер и образ. В частности, будет объяснена разница между просто контейнером и запущенным контейнером.

Перевод материала «P2P Salary Review».

Как и почему я реализовал P2P опрос для расчета зарплат в корпорации: конкретный пример

Цель: честная оптимизация

CEO компании поднял минимальную зарплату в компании до £45,000, и некоторые сотрудники покинули компанию из-за этого. Знаете почему? Потому что образованные, вкалывающие люди отказались принимать факт того что обычные работяги, не инвестирующие в свое развитие столько сил и времени стали получать те же деньги.

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

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

Честность это самый важный аспект любой зарплатной системы. Честность, это то, ради чего мы оптимизируем.

Имейте ввиду, то что ваша компания это часть большой системы (индустрии). Этой системе не важно как ты справедлив, но ты не можешь недоплачивать своим людям. Ты должен быть честным и конкурентным. В противном случае, восторжествует справедливость, которая называется «найти работу получше», и накажет вас.

Привет! Меня зовут Сергей Константинов, в Яндексе я руковожу разработкой API Карт. Недавно я поделился опытом поддержки обратной совместимости со своими коллегами. Мой доклад состоял из двух неравных частей. Первая, большая, посвящена тому, как правильно разрабатывать API, чтобы потом не было мучительно больно. Вторая же про то, что делать, если вам нужно что-то рефакторить и не сломать по дороге обратную совместимость.



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

Для разработчика обратная совместимость в первую очередь подразумевает, что единожды принятое обязательство предоставлять какую-либо функциональность невозможно отменить, исправить или перестать поддерживать.

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Расскажу как внедрить в существующее java приложение ssh сервер, который может выводить в терминал данные о лучших статьях с habrahabr. Это лишь пример, но на его основе вы сможете получить дополнительное средство для администрирования вашей программы и расширить поведение любыми командами, без изменения исходного кода и пересборки приложения.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.