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

В новой версии Java 8 наконец-то появились долгожданные лямбда-выражения. Возможно, это самая важная новая возможность последней версии; они позволяют писать быстрее и делают код более ясным, а также открывают дверь в мир функционального программирования. В этой статье я расскажу, как это работает.

Java задумывалась как объектно-ориентированный язык в 90-е годы, когда объектно-ориентированное программирование было главной парадигмой в разработке приложений. Задолго до этого было объектно-ориентированное программирование, были функциональные языки программирования, такие, как Lisp и Scheme, но их преимущества не были оценены за пределами академической среды. В последнее время функциональное программирование сильно выросло в значимости, потому что оно хорошо подходит для параллельного программирования и программирования, основанного на событиях («reactive»). Это не значит, что объектная ориентированность – плохо. Наоборот, вместо этого, выигрышная стратегия – смешивать объектно-ориентированное программирование и функциональное. Это имеет смысл, даже если вам не нужна параллельность. Например, библиотеки коллекций могут получить мощное API, если язык имеет удобный синтаксис для функциональных выражений.

Главным улучшением в Java 8 является добавление поддержки функциональных программных конструкций к его объектно-ориентированной основе.

Текст написан по мотивам выступления руководителя студии «Сибирикс» Владимира Завертайлова на летней партнерской конференции «1С-Битрикс» BitrixSummerFest и представляет личное мнение выступавшего.

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

Тема это болезненная, и говорить о ней открыто не любят. Конечно, каждому хотелось бы работать в коллективе, где никто и никого не наказывает. Увы, но теория управления пока не дает нам рецептов построения совершенно бесконфликтных коллективов, в которых все работают ответственно и с полной самоотдачей, не проявляя никаких пороков в рабочее время, где начальники сплошь тактичны и мудры. Впервые о проблематике наказаний я задумался несколько лет назад, сидя в офисе часов в 12 ночи. В тот момент я, будучи директором компании, выполнял обязанности программиста. Я отлаживал код, написанный сотрудником, который всё бросил, не дописал и ушел домой. В скайп стучится заказчик, пишет грозные слова, «срочно, всё пропало», давит и торопит меня. А в таких ситуациях у меня начинает болеть спина. И я сидел и думал, а что для программиста означает «нести ответственность за проект»?

Скажем, я, как директор, за срыв проекта огребаю по полной, в первую очередь — финансово. Ведь вся ответственность за работу компании лежит на директоре. А как быть с программистом или дизайнером?

Некоторое время назад после волшебного пендаля под названием Tolstoy Summer Camp я начал пилить свой стартап.
Сначала у меня в команде было два разработчика и дизайнер. Потом один разработчик ушёл пилить свой проект. Затем появился другой разработчик. И всё бы ничего, но я сходил с ума от того что не мог найти простых и понятных средств ведения дел в таких маленьких компаниях как моя.
Я перепробовал тучу всяких Basecamp, Asana, Redmine, Trello, Мегаплан и прочих, массу мессенджеров в разных сочетаниях c он-лайн файлопомойками типа Dropbox и GoogleDrive — ничего мне не нравилось. «Ну, не то это всё, не то!».

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

Информационная революция
Мы являемся свидетелями двух революционных процессов:

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

Если мы посмотрим внимательно на жанровое разнообразие в игровой индустрии (сразу оговорюсь, я имею в виду сюжетные single-player игры, не касаясь mmorpg и казуальщины), то мы обнаружим, что оно существенно деградировало по сравнению с 90-ми годами. Жанр квеста исчез совсем, TBS находится на грани вымирания. Существенно сократилось поголовье классических RPG типа Baldur Gate, Planescape Torment (т.е. таких RPG, где надо думать головой при билде персонажа). Стало значительно меньше игр с оригинальной игровой механикой (типа Settlers I-II). Собственно, за меня здесь уже всё сказали, см. картинку слева.

Большая часть современных игр — это какая-то помесь RPG от первого лица, шутера и аркады. При этом, что характерно, на разработку этих игр тратится очень много денег, так что проблема явно не в желании издателя сэкономить. Ровно то же самое произошло и с музыкой: всё многообразие жанров (опера, симфония, соната, фуга, etc.) в классическом искусстве деградировало ровно до одного — песни. И, если я не ошибаюсь в своих предположениях, то очень скоро с геймдевом произойдёт то же самое.

Собственно, если некоторые студии перестанут регулярно выкапывать труп стюардессы (см. Might & Magic Heroes VI, Civilization V, Diablo 3, etc), то это может произойти прямо завтра. Почему же? Что общего у геймдева 90-х и классической музыки?

Карты от SimCity китайского поисковика Baidu.

Небольшой фантастический рассказ о недалёком будущем.

[..]Несколько лет назад мне поступил заказ — написать алгоритм поиска замкнутых социальных кругов. То есть находить в сети «Люди» группы, которые связаны только друг с другом. Как обычно, я справился за ночь, а оставшееся по срокам время потратил на исследование сети, пользуясь доступом к серверу, что мне дали для работы. Любопытство — вот моё преступление.[..]

В нашем проекте так сложилось, что мы для нашей гео-вики стали использовать OSM а не GM. В ходе написания мобильного клиента под андроид был использован стандартный компонент MapView. Но, в ходе тестирования выявились расхождения в координатах OSM и GM, которые, в некоторых случаях, достигали 30 метров. Таким образом было решено переходить с карт гугла на OSM для чего и была найдена соответствующая библиотека osmdroid. О том, как переехать на эту библиотеку, расскажу под катом.

Ни для кого не секрет, что проектирование структуры БД является одной из основных и порой очень трудозатратных задач при разработке любого ПО, работающего с данными. Все мы так или иначе проектируем БД, пытаясь представить себе схему взаимосвязей таблиц, а зачастую рисуем, визуализируем структуру БД, прежде чем перенести ее в СУБД. Для моделирования баз данных MySQL есть MySQL Workbench, поставляемый разработчиком, для MS SQL есть Database Diagrams; я до недавнего времени пользовался Dia, а кто-то, может быть, использует для этих целей MS Visio. Но для PostgreSQL я не встречал ни одного адекватного решения, которое позволяло бы максимально просто и точно перенести наброски структуры БД в код ее создания в самой СУБД.

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



Итак… (текст, много картинок)

Как известно, до этого в nginx не было поддержки WebSockets:
habrahabr.ru/post/124089
habrahabr.ru/post/96354

18 февраля 2013 в trunk nginx была добавлена поддержка WebSockets (http://trac.nginx.org/nginx/changeset/5073/nginx), что открывает перед разработчиками новые горизонты.

Ждём выхода релиза.

Пару недель назад разработчики Google Chromium опубликовали новость о поддержке технологии WebSocket. В айтишном буржунете новость произвела эффект разорвавшейся бомбы. В тот же день различные очень известные айтишники опробовали новинку и оставили восторженные отзывы в своих блогах. Моментально разработчики самых разных серверов/библиотек/фреймворков (в их числе Apache, EventMachine, Twisted, MochiWeb и т.д.) объявили о том, что поддержка ВебСокетов будет реализована в их продуктах в ближайшее время.
Что же такого интересного сулит нам технология? На мой взгляд, WebSocket — это самое кардинальное расширение протокола HTTP с его появления. Это не финтифлюшки, это сдвиг  парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать.

Я считаю, что веб сокеты придутся ко двору, если вы разрабатываете:
— веб-приложения с интенсивным обменом данными, требовательные к скорости обмена и каналу;
— приложения, следующие стандартам;
— «долгоиграющие» веб-приложения;
— комплексные приложения со множеством различных асинхронных блоков на странице;
— кросс-доменные приложения.

Известно, что SQL — декларативный язык, который указывает, «что» мы хотим выбрать из базы, а «как» это сделать — СУБД решает сама. Задачу выбора для SQL-запроса конкретного способа его выполнения(плана) решает планировщик запросов, который есть практически в любой СУБД. Но иногда он выбирает не самый лучший план. Многие коммерческие СУБД предоставляют на этот случай «хинты», которые позволяют в ручном режиме подсказывать базе, как лучше выполнить запрос. В Open Source СУБД PostgreSQL такого механизма не было.

И вот, наконец, случилось то, о чем многие мечтали и чего уже устали ждать, а другие боялись. Японские разработчики из NTT реализовали хинты планера PostgreSQL. Причем, им удалось это сделать, не меняя ядро, в виде отдельного модуля pg_hint_plan, поддерживающего версии PostgreSQL 9.1 и 9.2. Модуль реализует хинты, позволяющие устанавливать методы сканирования и соединения таблиц, установку значений GUC. За деталями установки и использования добро пожаловать под кат.

Сейчас на рынке много предложений по продаже мобильных устройств, предназначенных для контроля движущихся объектов или трекеров. В большинстве из них есть функция передачи информации по GPRS на любой заданный веб-адрес через определенный интервал времени. Чаще всего формат передачи данных разный. Поэтому мы не будем рассматривать вопрос загрузки данных с трекера в базу. Предположим данные есть и мы хотим приступить к созданию сервиса мониторинга транспорта. Основу такой системы образуют возможности:
-выбор карты и ее отображение
-отображение точки или картинки и подписи к ней
-отображение полигона и его редактирование
-отображение линии и ее редактирование
-отображение информации связной с полигонами, линиями, точками (всплывающие подсказки)
-немного математики (подсчет пройденного пути, площадь полигона, принадлежность точки полигону)
Все эти функции легко реализовать с помощью OpenLayers, библиотеки на JavaScript.

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

Выглядит реклама приблизительно следующим образом:

Так уж сложилось, что последние несколько лет я занимал самые разнообразные руководящие должности в полудюжине компаний, занимающихся разработкой программного обеспечения разного рода. Довелось побывать и тимлидом, и менеджером проекта, и группы проектов, руководителем отдела и руководителем технического направления; подопечных бывало от двух до ста пятидесяти человек, да и размеры компании варьировались от трёх до двухсот тысяч работников. Неизменным оставалось только одно: чисто управленческая работа, постепенный и окончательный отход от технических задач.

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

Маленькое предварительное замечание: Подробное объяснение потребовало бы объёмов средней книжки. Тут всё дано схематично, кратко и без подробностей. Текст, конечно, хулиганский, но прежде чем наезжать на автора, стоит учесть, что за ним стоит двадцать лет опыта и много-много литературы как классической, так и специалистам ИТ не ведомой.

Есть слово, приносящее индустрии каждый год огромные убытки. И слово это — bug.

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

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

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

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

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

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

Код именно отражает, а не описывает. Последнее возможно, но требует перестройки всего процесса, от форматов записи до мозгов.

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

Писать и говорить то, что думаешь, — это всегда отсутствие такта, презрение к окружающим и хамство. Если кто-то ставит в своём коде комментарий «Stupid idea. Does not work, if N < 0. Correct ASAP.», он рискует прослыть минимум странным. А вот если это попадёт в участок ответственности гениального программиста, тут уже мелкой истерикой не ограничится. Даже, если «stupid» будет подразумеваться только по контексту. Или напишите в комментарии что-нибудь типа «I do not know why this works, but otherwise the function generates an exception.» Потом покажите это начальнику и попросите повышения.

И, конечно, гораздо выгоднее говорить «Мы исправляем баги в коммуникационном модуле», а не «Читая документацию мы прошляпили несколько критических моментов и неделю будем всё с нуля переделывать.»

Ладно, оставим. Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже… Короче, фиг с ним, перейдём к плюшкам.

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

Диспозиция:

компания решила создать свой небольшой ЦОДик (рассказ о нем — дело отдельного разговора), и перевести на него работу всей филиальной сети (несколько десятков), ну да неважно. Необходимо было построить отказоустойчивою систему на XenDesktop для подключения > 500 пользователей, виртуальные столы – windows 7.
Решения для виртуальных рабочих столов было выбрано от компании Citrix – XenDesktop. Никакие внешние интеграторы не привлекались. Время выполнения – как обычно “надо уже вчера”.

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

1. Parted Magic OS: дистрибутив для восстановления дисков и работы с разделами, который поддерживает более десяти файловых систем и включает различные утилиты для «переноса, копирования, создания, удаления, расширения и сжатия дисковых разделов. Клонирование дисков и осуществление полного бэкапа. Тестирование дисков на возможность сбоя в будущем. Поиск сбойных секторов. Тестирование производительности компьютера. Безопасная полная очистка диска без возможности восстановления. Доступ к незагружаемым HDD для восстановления важных данных».

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

• Поддержка юнити игр
• Дружелюбность к пользователю
• Отображение игровых новостей
• Универсальность для всех игр разработанных нашей студией
• Гибкость настройки
• И самое важное: умение делать небольшие патчи для больших файлов

Ссылка на исходники патчера в конце статьи.