В TDD-сообществе существует совет, который говорит о том, что мы не должны использовать mock-объекты для типов, которыми не владеем. Я считаю, что это хороший совет, и стараюсь следовать ему. Конечно, есть люди, которые говорят, что мы вообще не должны использовать mock-объекты. Независимо от того, какого мнения вы придерживаетесь, совет «не имитировать то, что не ваше» – содержит в себе еще и скрытый смысл. Люди часто пропускают его мимо ушей, видя слово «mock» и впадая в ярость.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Why should you return early?» автора Szymon Krajewski



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

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

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

Одним из параметров оценки кода служит его чистота. Создатель языка моделирования UML Гради Буч (Grady Booch) писал:

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

Сегодня мы собрали для вас список книг и статей по этой теме, которые рекомендуют к прочтению резиденты Hacker News, Stack Exchange и других профильных платформ.

Этот пост просто шутка и не пытается выставить инструменты, упомянутые здесь, в дурном свете. Я использую их постоянно, они великолепны, и я рекомендую их использовать. По мотивам It's the future @ CircleCI Blog

— Эй, я бы хотел научиться писать крутые веб-приложения. Слышал, у тебя есть опыт.

— Да, я как раз занимаюсь фронтендом, юзаю пару тулз.

— Круто. Я щас делаю простое приложение — обычный TODO-лист, используя HTML, CSS и JavaScript, и планирую заюзать JQuery. Это норм?

— Не-не-не. Это олдскул. Джиквери мёртв — никто не использует его теперь! Тебе нужен React. Это будущее.

— Окей, лады. А что это?

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

— Это теперь называется Front-End инженер, но да, я — именно он. Я работаю с вебом в 2016. Визуализации, музыкальные плееры, летающие дроны, которые играют в футбол, все что угодно. Я только что вернулся из JsConf и ReactConf, так что я знаю новейшие технологии для создания веб-приложений.

— Круто. Мне нужно создать страницу, которая отображает последние действия со стороны пользователей, так что мне просто нужно получить данные от REST и отобразить их в какой-то фильтруемой таблице, ну и обновлять её, если что-то изменится на сервере. Я думал, может быть, использовать JQuery для извлечения и отображения данных?

— О, Мой Бог! Нет! Никто больше не использует JQuery. Ты должен попробовать React: это — 2016!

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

В прошлом году на тихие дороги округа Монмут, Нью-Джерси, вышел странный робомобиль. Экспериментальное средство передвижения, разработанное исследователями из Nvidia, внешне не отличалось от других робомобилей, но оно было совершенно не таким, какие разрабатывают в Google, Tesla или General Motors, и оно продемонстрировало растущую мощь ИИ. Автомобиль не следовал строгим инструкциям, запрограммированным человеком. Он полностью полагался на алгоритм, обучившийся водить машину, наблюдая за людьми.

Создать таким образом робомобиль – достижение необычное. Но и немного тревожное, поскольку не до конца ясно, каким образом машина принимает решения. Информация из датчиков идёт напрямую в большую сеть искусственных нейронов, обрабатывающую данные и выдающую команды, необходимые для управления рулём, тормозами и другими системами. Результат похож на действия живого водителя. Но что, если однажды она сделает что-нибудь неожиданное – въедет в дерево, или остановится на зелёный свет? В текущей ситуации будет очень сложно выяснить причину такого поведения. Система настолько сложна, что даже разработавшие её инженеры с трудом смогут найти причину любого конкретного действия. И ей нельзя задать вопрос – не существует простого способа разработать систему, способную объяснить свои действия.

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

«Это все только для хайлода» — скажет вдумчивый и прозорливый читатель. Плох тот веб-проект, который не мечтает стать популярным хайлодом.

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

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

Откладывание рефакторинга на потом ведет к увеличению технического долга и созданию задач (user story) на рефакторинг, которые не имеют business value для product owner-a, а соответственно такие задачи не будут попадать в топ продуктового беклога.

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

Отправная точка

По мере развития игры игровых объектов становится все больше и больше, компании растут и обсчитывать игровую ситуацию становится все сложнее и сложнее. Транзакции повисали по таймауту и игровые объекты сохраняли свое состояние с ошибками, что приводило в свою очередь к другим ошибкам. В логах сервера с завидной регулярностью писалось о следующей проблеме: Lock wait timeout exceeded; try restarting transaction.

Google явного решения не давал, общая рекомендация заключалась в прочесывании бизнес-логики.

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

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

В общем — ситуацию надо было спасать. Засучив рукава, мы начали с чистого листа искать решение.

Вводная

Когда часто сталкиваешься с какой-либо технологией, языком программирования, стандартом, формируется некая картина их возможностей, границы, в которых они используются. Так может продолжаться достаточно долго, пока на глаза не попадаются примеры, которые расширяют затвердевшие горизонты знания. Сегодня, я хотел бы рассказать о таких примерах и продемонстировать их для языка SQL. Интересные и редкие конструкции, забытые выражения, странные приемы ждут Вас в этой статье. Кого заинтересовал, добро пожаловать под кат.

К сожалению, у меня нет опыта работы с микросервисами, но около года назад я очень активно интересовался этой темой и изучил все источники информации, какие смог найти. Я просмотрел несколько выступлений на конференциях, прочитал несколько статей очень авторитетных и опытных специалистов вроде Мартина Фаулера, Фреда Джорджа, Эдриана Кокрофта и Криса Ричардсона, чтобы как можно больше узнать о микросервисах. Эта статья — результат моих изысканий.

Добрый день.

Представляю на суд общественности материал о том, как я за четыре месяца получил визу, переехал в Германию и нашел там работу.

Считается, что для переезда в другую страну нужно сначала долго искать работу удаленно, потом, в случае успеха, ждать решения по визе, и лишь после паковать чемоданы. Я решил, что это далеко не оптимальный способ, поэтому пошел другим путем. Вместо того, чтобы искать работу удаленно, я получил так называемую «визу на поиск работы», въехал в Германию, нашел здесь работу и уже после подал документы на Blaue Karte. Во-первых, в этом случае документы не ездят из страны в страну, и время ожидания визы значительно уменьшается. Во-вторых, поиск работы на месте радикально повышает ваши шансы, и это тоже заметно ускоряет процесс.

Привет.

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

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

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

При создании сайтов часто возникает задача создания админки для редактирования контента. Задача, в общем, тривиальная, но сделать удобную админку не так-то просто.

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

Всем известный jQuery-плагин tablesorter с tablesorterPager-ом и менее известный, но гораздо более функциональный DataTables хороши, но обладают некоторыми недостатками. Главный из них — сложность динамического добавления новых строк в таблицу (после добавления строки в таблицу, новая строка потеряется при следующем вызове сортировки). tablesorter вообще не даёт средств для добавления строки в свой кэш, DataTables предоставляет широкое и функциональное API для управления внутренним представлением таблицы, но это API довольно многословно и не очень гибко.

Хочу предоставить общественности реализацию админки на относительно новой javascript-фреймворке AngularJS. Будет создана страничка для редактирования списка вопросов, разбитых по категориям и отвечающим. В статье нет сравнения с другими подобными фреймворками, но нет и простого повторения официальной документации, я постараюсь поделиться своим опытом в использовании фреймворка и расскажу о нескольких интересных приёмах работы с ним.

Сразу приведу, что получится в итоге (кликабельно):

Одним из самых значительных событий, произошедших в мире PHP в 2015 году, стал выпуск PHP 7. Целых 10 лет отделяют его от выпуска первого релиза PHP с номером 5. С увеличением первой цифры в номере версии, в PHP 7 появилась масса новшеств, увеличилась и скорость работы.
Однако в седьмой версии была убрана устаревшая функциональность, что привело к некоторым проблемам с обратной совместимостью, затруднив перевод старых приложений на новую версию. Эта статья может послужить вам кратким руководством, если вы планируете написание новых или перевод своих существующих приложений на PHP 7.

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

Проектирование

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

Меня зовут Евгений и я жаворонок. Сегодня проснулся в 6 утра, открыл окно в кухне, заварил кофейку и решил глянуть, «что нового». Мне написал мой бывший коллега «Андроид»… Точнее «Андроид-разработчик» Максим, но так звучит фантастичнее…



Он спросил:

– Женя, привет. (wave) Вопрос к тебе, как мега лайв хакеру. Сколько времени нужно спать, что бы мозг отдохнул и можно было плодотворно работать? Умные будильники сильно помогают?

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

Как правило, статьи о кешировании начинаются за здравие, а заканчиваются LRU кешем. Попробуем переломить эту тенденцию? Начнем с того, чем LRU плох, а закончим за здравие. Я надеюсь.

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

«Если человек, рождённый слепым, может на ощупь различать формы предметов, такие как сфера и куб, сможет ли он, получив способность видеть (но уже без помощи осязания), определить эти объекты только при помощи зрения, соотнеся их с имеющимся у него тактильным представлением?» Так звучит задача Молинью, мысленный эксперимент, сформулированный в 1688 году. И сам Уильям Молинью, и Джон Локк, в письме к которому он описал эту задачу, склонялись к отрицательному ответу.



Значительную часть информации зрячий человек получает благодаря глазам. Часто мы сознательно «лишаем» себя одного из органов, полезных для ориентации в пространстве — затыкаем уши наушниками и слушаем музыку, получая удовольствие. Человек, потерявший зрение в сознательном возрасте, продолжает мыслить обычными для зрячего категориями — он представляет картинки происходящего, мозг создаёт их из получаемой от других органов информации. Те же, кто родился слепым, видят мир иначе. Если потерявший зрение человек представит отдых на море, «увидев» воду и песчаный пляж, то слепой от рождения почувствует песок между пальцами и бриз на коже, услышит звуки волн. Даже после восстановления зрения мозг этих людей не сразу способен воспринять определённые предметы и явления.