Предисловие

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

Тут другое дело. PHP не просто неудобен в использовании, плохо мне подходит, субоптимален или не соответствует моим религиозным убеждениям. Я могу рассказать вам много хороших вещей о языках, которых я стараюсь избегать, и много плохих вещей о языках, которые мне нравятся. Вперёд, спрашивайте! Получаются интересные обсуждения.

PHP — единственное исключение. Фактически каждая деталь PHP в какой-то мере поломана. Язык, структура, экосистема: всё плохо. И даже нельзя указать на одну убийственную вещь, настолько дефект систематичный. Каждый раз, когда я пытаюсь систематизировать недостатки PHP, я теряюсь в поиске в глубину обнаруживая всё больше и больше ужасных мелочей(отсюда фрактал).

PHP — препятствие, отрава моего ремесла. Я схожу с ума от того, насколько он сломан и насколько воспеваем каждым уполномоченным любителем нежелающим научиться чему-либо ещё. У него ничтожно мало оправдывающих положительных качеств и я бы хотел забыть, что он вообще существует.

В Java для введения порядка среди определённых объектов можно написать компаратор — класс, содержащий функцию compare, которая сравнивает два объекта. Альтернативой компаратору является естественный порядок объектов: объект реализует интерфейс Comparable, который содержит метод compareTo, позволяющий сравнить этот объект с другим. Сравнивающая функция должна вернуть 0, если объекты равны, отрицательное число (обычно -1), если первый объект меньше второго, и положительное число (обычно 1), если первый больше. Обычно реализация такой функции не представляет сложностей, но имеется один случай, о котором многие забывают.

Сравнение используется различными алгоритмами от сортировки и двоичного поиска до поддержания порядка в сортированных коллекциях вроде TreeMap. Эти алгоритмы завязаны на три важных свойства сравнивающей функции: рефлексивность (сравнение элемента с самим собой всегда даёт 0), антисимметричность (сравнение A с B и B с A должны дать разный знак) и транзитивность (если сравнение A с B и B с C выдаёт одинаковый знак, то и сравнение A с C должно выдать такой же). Если сравнивающая функция не удовлетворяет этим свойствам, алгоритм может выдать совершенно непредсказуемый результат. Причём скорее всего вы не получите никакого исключения, просто результат будет неверный.

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

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

Самая главная характеристика подстанции — уровни напряжения по верхней и нижней стороне. То что написано в заголовке как раз и означает что на верхней стороне 220 тысяч вольт, а на нижнем два уровня напряжения 110 и 20 кВ. То есть по сути это две подстанции на одной территории. А в нашей розетке согласно классификации энергетиков 0,4кВ, это потому. что между фазами 400 вольт (раньше было 380 но стандарты давно поменялись).

Привет, Хаброжители! Эта книга всерьез пересматривает суть и принципы объектно-ориентированного программирования (ООП) и может быть метафорически названа «ООП Лобачевского». Егор Бугаенко, разработчик с 20-летним стажем, критически анализирует догмы ООП и предлагает взглянуть на эту парадигму совершенно по-новому. Так, он клеймит статические методы, геттеры, сеттеры, изменяемые методы, считая, что это — зло. Для начинающего программиста этот томик может стать просветлением или шоком, а для опытного является обязательным чтением.

Отрывок «Не используйте статические методы»

Ах, статические методы… Одна из моих любимых тем. Мне понадобилось несколько лет, чтобы осознать, насколько важна эта проблема. Теперь я сожалею обо всем том времени, которое потратил на написание процедурного, а не объектно-ориентированного программного обеспечения. Я был слеп, но теперь прозрел. Статические методы — настолько же большая, если не еще большая проблема в ООП, чем наличие константы NULL. Статических методов в принципе не должно было быть в Java, да и в других объектно-ориентированных языках, но, увы, они там есть. Мы не должны знать о таких вещах, как ключевое слово static в Java, но, увы, вынуждены.. Я не знаю, кто именно привнес их в Java, но они — чистейшее зло.. Статические методы, а не авторы этой возможности. Я надеюсь.

Закрадывалась ли вам в голову идея переписать своё жирное энтерпрайзное приложение с нуля? Если с нуля, то это ж ого-го. Как минимум кода будет раза в два меньше, верно? Но ведь пройдёт пара лет, и оно тоже обрастёт, станет легаси… времени и денег на переписывание не так много, чтобы делать идеально.

Успокойтесь, начальство всё равно не даст ничего переписать. Остаётся рефакторить. На что лучше всего потратить свои невеликие ресурсы? Как именно рефакторить, где проводить чистки?

Название этой статьи — в том числе отсылка к книге Дяди Боба «Чистая Архитектура», а сделана она на основе замечательного доклада Victor Rentea (твиттер, сайт) на JPoint (под катом он начнёт говорить от первого лица, но пока дочитайте вводную). Чтения умных книжек эта статья не заменит, но для такого короткого описания изложено весьма хорошо.

Идея в том, что популярные в народе вещи вроде «Clean Architecture» действительно являются полезными. Сюрприз. Если нужно решить вполне конкретную задачу, простой изящный код не требует сверхусилий и оверинжиниринга. Чистая архитектура говорит, что нужно защищать свою доменную модель от внешних эффектов, и подсказывает, как именно это можно сделать. Эволюционный подход к наращиванию объема микросервисов. Тесты, которые делают рефакторинг менее страшным. Вы ведь уже знаете всё это? Или знаете, но боитесь даже подумать об этом, ведь это же ужас что тогда делать придётся?

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

Привет, Хабр! Меня зовут Андрей Гоменюк, я тимлид одной из команд серверной разработки Badoo.

На майском Badoo Techleads Meetup, посвящённом управлению разработкой, я поделился опытом интеграции новичков в команду. А сегодня делюсь текстовым дополненным и улучшенным вариантом своего доклада.

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

Я уже достаточно много лет занимаюсь разработкой на java и повидал довольно много чужого кода. Как это не странно, но постоянно от одного проекта к другому я вижу одни и те же проблемы. Этот топик — попытка ликбеза в наиболее часто используемых конструкциях языка. Часть описанного — это довольно банальные вещи, тем не менее, как показывает мой опыт, все эти банальности до сих пор актуальны. Надеюсь, статья пригодится многим java программистам. Итак, поехали:

new vs valueOf

//медленно
Integer i = new Integer(100);
Long l = new Long(100);
String s = new String("A");

//быстро
Integer i = Integer.valueOf(100);
Long l = 100L;//это тоже самое что Long.valueOf(100L);
String s = "A";

Старайтесь всегда использовать метод valueOf вместо конструктора в стандартных классах оболочках примитивных типов, кроме случаев, когда вам нужно конкретно выделить память под новое значение. Это связано с тем, что все они, кроме чисел с плавающей точкой, от Byte до Long имеют кеш. По умолчанию этот кеш содержит значения от -128 до 127. Следовательно, если ваше значение попадает в этот диапазон, то значение вернется из кеша. Значение из кеша достается в 3.5 раза быстрее чем при использовании конструктора + экономия памяти. Помимо этого, наиболее часто используемые значения могут также быть закэшированы компилятором и виртуальной машиной. В случае, если ваше приложение очень часто использует целые типы, можно увеличить кеш для Integer через системное свойство «java.lang.Integer.IntegerCache.high», а так же через параметр виртуальной машины -XX:AutoBoxCacheMax=<size>.

Программирую на Java вот уже 7 лет. Но на работе часто приходится обучать новое поколение. В связи с этим и решил сделать некоторую шпаргалку, которая, надеюсь, пригодится и для хабрчан. Если кто-то может помочь дополнить чем-то информацию из этой статьи, то пишите! Итак:

Основные ресурсы для начального обучения

• www.javable.com — сайт со статьями и tutorial'ом по Java. Все в основном на русском.
• www.exampledepot.com — очень полезный ресурс, где собраны краткие примеры использования классов для тех или иных пакетов
• java.sun.com — без первоисточника не обойтись. Для любого Java программиста JavaDoc должен быть истиной в последней инстанции. Так же здесь можно найти серию tutorial'ов на все возможные темы.

Java — очень распространённая платформа, на ней пишут очень разные вещи, начиная от Big Data, заканчивая микросервисами, монолитами, enterprise и прочим. И, как правило, всё это развёртывают на Linux серверах. При этом, соответственно, те люди, которые пишут на Java, зачастую делают это совсем на других операционных системах. Там они:

• пишут код;
  
• отлаживают, тестируют;
  
• после этого упаковывают в jar;
  
• отправляют на Linux, и оно работает.
  

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



С другой стороны, есть те, кто занимается администрированием серверов, на их сервера устанавливают JVM, отправляют jar и war-файлы, а с точки зрения мира Linux все это:

• чужеродное;
  
• проприетарное;
  
• собирается не из исходников;
  
• поставляется какими-то jar-архивами;
  
• «отъедает» всю память на сервере;
  
• вообще, ведёт себя не по-человечески.
  

Цель доклада Алексея Рагозина на Highload++, расшифровка которого идет далее, была в том, чтобы рассказать особенности Java для «линуксоидов» и, соответственно, Linux — Java-разработчикам.

Давайте сегодня поговорим о социопатах. И об их противоположности – командных игроках.

Появилась у меня игра «Совушки, ау», и я прям остро всё прочувствовал. Она командная, и сделана так, что победить в ней могут только те, кто работает на общее благо. Причём часто делая тактически невыгодные ходы, но стратегически перспективные. Если идею поймёт другой игрок.

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

Но внятным правилам подчиняются лишь взрослые. Дети же безумны.

– Нет, коллеги, так дело не пойдет! С этого дня мы вводим новый порядок совещаний, отчетности и управления. Иначе наша компания на полной скорости угодит в пропасть. Такие ситуации, как на прошлой неделе, недопустимы! Это и моя, и ваша вина. С себя я ответственности не снимаю, и вам настоятельно рекомендую – нет, не рекомендую, а приказываю немедленно изменить отношение к своим служебным обязанностям! Вы – руководители, а не линейные исполнители!

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

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

Первая в списке — «Агрессия» Конрада Лоренца. Она вообще-то про зверей и людей, но эта штука настолько системная и захватывающая, что прямо накладывается на бизнес. Ну и просто на жизнь. Особенно интересны выкладки про уровень агрессии в разных сообществах. Ну и у него описаны баги разных зверей, что меня лично всегда дико радует.

Коллаборация — Мортен Хансен
Это инструкция по совместной работе и взаимодействию между людьми в команде и командами. Она меня здорово успокоила рядом исследований, например, тем, что вообще-то не надо заниматься нетворкингом, если ты занимаешься делом. Не надо знать 200-400 человек, чтобы найти нужного — надо знать 10 человек, каждый из которых знает по 50-100. А это в разы проще и эффективнее. Нетворкинг для интроверта — это прекрасно.

Привет, Хабр! Представляю вашему вниманию перевод статьи "REST API Best Practices" автора Krishna Srinivasan.

REST становится общим подходом для представления сервисов окружающему миру. Причина его популярности заключается в его простоте, легкости использования, доступе через HTTP и другие. Существует неправильное представление о том, что все данные, доступные через сеть, считаются REST, но это не так. В этой статье я собираюсь объяснить вам некоторые best practices, которые вы должны всегда помнить при реализации собственного REST приложения. Я бы хотел услышать ваш опыт в REST приложениях, поэтому если вы знаете best practies, которые не упомянуты в этой статье, пожалуйста, поделитесь с нами в комментариях.

Disclamer: все best practies основаны на моем личном опыте. Если вы имеете другое мнение, не стесняйтесь отправлять его мне на email, и мы обсудим его.

Здесь представлен список best practices, которые будут обсуждаться в этой статье:

1. Конечные точки в URL – имя существительное, не глагол
2. Множественное число
3. Документация
4. Версия вашего приложения
5. Пагинация
6. Использование SSL
7. HTTP методы
8. Эффективное использование кодов ответов HTTP

Это старая версия статьи, новую вы можете найти перейдя по ссылке

И, тем не менее, ум человеческий тщетно пытался постигнуть ее в течение более чем 2 000 лет, между тем как, с другой стороны, ему удался, но крайней мере приблизительно, анализ гораздо более содержательных и сложных форм. Почему так? Потому что развитое тело легче изучать, чем клеточку тела. К тому же при анализе экономических форм нельзя пользоваться ни микроскопом, ни химическими реактивами. То и другое должна заменить сила абстракции.

Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.

О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.

Многие авторы используют его «по умолчанию», как термин «интуитивно понятный» без расшифровки, либо вообще вносят дополнительную путаницу использованием альтернативной терминологии, например, пишут вместо бизнес-процесса «бизнес сущность» и т.д.

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

^{Кадр из к/ф «Операция Ы и другие приключения Шурика»}

Как говорят, «кризис — пора возможностей». И поэтому сейчас самое время начать вкладывать в саморазвитие, осваивать новую профессию или повышать свою квалификацию. Займитесь изучением языков программирования, обретением навыков разработки, тестирования и вообще всячески прокачивайте свой IT-скилл. Ведь чем больше вы знаете, тем прочнее будете стоять на ногах. А чтобы вам было легче сориентироваться и выбрать направление, мы сделали подборку наших бесплатных образовательных материалов, курсов и инициатив за 2015–2016 годы.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

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

Сегодня я решил опубликовать свои шпаргалки, на самые часто встречающиеся ошибки при работе с MySQL.

Улучшаем дизайн проекта с помощью тактически грамотных действий, а не таланта.

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

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

Легко опустить руки и сказать: «Я никогда не смогу сделать это должным образом, я не художник!», Но, оказывается, есть уйма ловких приёмов, которые вы сможете использовать, чтобы поднять свою работу на другой уровень, не имея опыта в графическом дизайне.

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

1. Для создания иерархии используем цвет и вес вместо размера

Регулярные выражения в Python от простого к сложному

Решил я давеча моим школьникам дать задачек на регулярные выражения для изучения. А к задачкам нужна какая-нибудь теория. И стал я искать хорошие тексты на русском. Пяток сносных нашёл, но всё не то. Что-то смято, что-то упущено. У этих текстов был не только фатальный недостаток. Мало картинок, мало примеров. И почти нет разумных задач. Ну неужели поиск IP-адреса — это самая частая задача для регулярных выражений? Вот и я думаю, что нет.
Про разницу (?:...) / (...) фиг найдёшь, а без этого знания в некоторых случаях можно только страдать.

Плюс в питоне есть немало регулярных плюшек. Например, re.split может добавлять тот кусок текста, по которому был разрез, в список частей. А в re.sub можно вместо шаблона для замены передать функцию. Это — реальные вещи, которые прямо очень нужны, но никто про это не пишет.
Так и родился этот достаточно многобуквенный материал с подробностями, тонкостями, картинками и задачами.

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

Этот список появился как личная памятка по темам, которые я обсуждал с коллегами и друзьями и в которых хотел разобраться поглубже…

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

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