На Хабре уже много писали о методологии БЭМ, выросшей в Яндексе. И мы решили, что пора системно рассказать о том, откуда она появилась и что сделало БЭМ таким, каким мы его знаем. Думаем, это будет интересно не только тем, кто уже использует БЭМ, но и тем, кто считает, что эта методология не подходит для их проектов. Возможно, они увидят, что мы решали проблемы, похожие на их собственные, и найдут что-то полезное для себя.



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

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

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

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

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

Пользователь: это невозможно, GPS съест батарейку
Джуниор: это возможно, используй Geofences
Сеньор: есть варианты и получше

На картинке сначала в одну, а потом в другую сторону одновременно с одним человеком «прогулялись» 6 одинаковых телефонов. Но какой разный результат!

Hello, Habr! Недавно мы получили от “Известий” заказ на проведение исследования общественного мнения по поводу фильма «Звёздные войны: Пробуждение Силы», премьера которого состоялась 17 декабря. Для этого мы решили провести анализ тональности российского сегмента Twitter по нескольким релевантным хэштегам. Результата от нас ждали всего через 3 дня (и это в самом конце года!), поэтому нам нужен был очень быстрый способ. В интернете мы нашли несколько подобных онлайн-сервисов (среди которых sentiment140 и tweet_viz), но оказалось, что они не работают с русским языком и по каким-то причинам анализируют только маленький процент твитов. Нам помог бы сервис AlchemyAPI, но ограничение в 1000 запросов в сутки нас также не устраивало. Тогда мы решили сделать свой анализатор тональности с блэк-джеком и всем остальным, создав простенькую рекурентную нейронную сеть с памятью. Результаты нашего исследования были использованы в статье “Известий”, опубликованной 3 января.



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

Деактивированная ядерная ракета Titan II в музее (Brendan Smialowski/Agence France-Presse)

В списке целей для ракетно-ядерных ударов в СССР наиболее впечатляюще выглядит пункт №275. Он называется очень просто — «население». Сам список был впервые опубликован Национальным управлением архивов и документации. Сам документ был разработан для 50-х годов прошлого века, когда угроза обмена ядерными ударами между США и СССР была весьма вероятным событием.

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

Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.

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

Многие знают про возможность хранить процедуры в sql базах данных, про это написано немало пухлых руководств и статей. Однако мало кто знает, что схожие возможности имеются и в Redis, начиная с версии 2.6.0. Но так как Redis не является реляционной БД, то и принципы описания хранимых процедур достаточно сильно отличаются. Хранимые процедуры в Redis — практически полноценные Lua скрипты (на момент написания статьи в качестве интерпретатора используется Lua 5.1).

После моего грандиозного тестирования батареек многие просили провести такие же основательные тесты NiMh-аккумуляторов. За четыре месяца я протестировал 198 аккумуляторов (44 модели AA и 35 моделей AAA).

Вступление

Предупреждаю сразу: технического в статье очень мало. Это практически пошаговая инструкция для не очень сведующих в техническом плане пользователей. Для людей сведущих (и тех, кому лень читать много текста), приведу две ссылки: Telegram Bots API + IFTTT Maker Channel.

Теперь подробнее. Думаю, все слышали про мессенджер Telegram. Вероятно, многие даже знают про нехитрый API для создания ботов в этом мессенджере. Кроме того, не так давно в T появилась возможность создавать так называемые «каналы» (channels), упрощающие мгновенную рассылку сообщений практически любому количеству подписавшихся на канал лиц. Наконец, самая свежая новость: ботов стало можно добавлять в качестве администраторов в каналы, то есть такие рассылки стало можно делать автоматизированно.

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

• три канала (@RedditTop, @r_pics, @gone_wild — осторожно, последний с «взрослым» контентом), которые ежечасно импортируют топовые посты с Реддита (и двух его сабреддитов);
• ещё канал, делающий то же с постами с 9GAG;
• и, наконец, завел хитрого бота @JamesBot, который анонимно пересылает все сообщения, написанные ему, в общий канал (@secret_ru, @secret_en, @secret_es, @secret_ar или @secret_fa — в зависимости от языка). Получился анонимный чат средней степени трэшовости.

Уже после создания всех этих ботов и каналов мне пришло в голову, что простейший автоимпорт постов откуда-то «снаружи» можно наладить вообще без всякого кода и хостинга — буквально минут за 5. На помощь нам придет прекрасный сервис IFTTT — If This Then That, имеющий множество интеграций с социальными сетями и прочими сервисами. Правда, к сожалению, прямой интеграции с Телеграмом у него (пока?) нет — зато есть т.н. IFTTT Maker Channel, позволяющий делать простые HTTP(S)-запросы при срабатывании триггера. К сожалению, мы не сможем принимать сообщения, отправленные боту (входящие запросы IFTTT Maker принимать может, но, увы, только в строго определенном формате) — интерактива не выйдет. Зато сможем по срабатывании любого события (например, новый твит или пост в FB):

• публиковать сообщение в канале,
• отправлять сообщение в заранее выбранный чат (куда добавлен наш бот),
• отправлять сообщение заранее указанному пользователю (который добавил себе бота).

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

Поехали. Многие мобильные приложения (и не только) используют архитектуру клиент-сервер. Общая схема, думаю, понятна.



Уделим внимание каждому элементу и отметим:

• сервер — представляет собой некую программу, работающую на удаленном компьютере, и реализующую функционал «общения» с приложениями-клиентами (слушает запросы, распознает переданные параметры и значения, корректно отвечает на них);
• клиент — в нашем случае, программа на мобильном устройстве, которая умеет формировать понятный серверу запрос и читать полученный ответ;
• интерфейс взаимодействия — некий формат и способ передачи/получения запросов/ответов обеими сторонами.

Неважно, как реализован любой из этих элементов, все они в любом случае присутствуют. Давайте реализуем примитивный сервер и Android клиент, работающий с ним. Как пример, будем использовать любой популярный мобильный интернет-мессенджер (Viber, ICQ), а приложение условно назовем «интернет-чат».

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

И всё же в какой-то момент понимаешь, что в документации есть не всё. И тут варианты решения задач появляются разные — можно открыть исходники Django, можно посмотреть, что пишут по этому поводу на Stackoverflow и в других местах (часто очень помогают списки рассылки, а также официальный Trac), но ещё лучше — всё это вместе.

Давайте рассмотрим всего несколько примеров того, что может понадобиться в повседневной работе, но чего (пока что) не прочтёшь в официальной документации. Впрочем, если вы считаете, что нужно добавить ещё что-то — пишите, может быть, это действительно так.

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

В данной статье будет рассмотрены вопросы, возникающие во время выбора Game Engine для разработки 2D игр. И, как вариант ответов на эти вопросы, будет предложено использовать Egret.

Дело было вечером, делать было нечего, но голова рукам покоя не давала и хотелось чего-то для души… А для души захотелось чего-то новенького, эдакого необычного.

Я, как и многие из хабровчан, люблю новинки. Релиз нового софта — это как праздник. Новые фичи, новые возможности… Новые способы забивать гвозди и кататься на велосипедах. Новые велосипеды… В общем можно придумать кучу аллегорий и метафор. А про что это я? Ах да, про Nginx, HTTP2 и JavaScript. Чем они связаны, спросите вы? А тем, что в последней версии Nginx (1.9.5) добавили много интересных плюшек, а именно:

• добавили протокол HTTP2 и удалили модуль SPDY (нафиг старое барахло)
• интегрировали прямо в nginx модуль ngx_http_js_module и создали свой диалект JavaScript

Го под кат, расскажу детали.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

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

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

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

Впервые я столкнулся с Upwork (тогда еще oDesk) в 2011м году, когда брат прислал на них ссылку в скайпе. Я только начинал работать на русских биржах, и подумал — почему бы не попробовать еще и на зарубежной. Но тогда все закончилось ничем. Результаты были слабыми, и, разочаровавшись во фрилансе как таковом, я бросил это дело.

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

Разбираемся, как медиа и контентно-ориентированные площадки должны повышать эффективность.