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

Недавно меня спросил один знакомый, как это все выдерживают мои глаза и зрение остается хорошим?! Я всегда отвечаю, что годы тренировок помогают. Думаете это сарказм? Только отчасти:) На самом деле это тренировки.

Всем привет!

Меня зовут Лариса. Я работаю в Google и веду блог на larrr.com, где я изначально и опубликовала эту статью.

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

На всякий случай – это не официальный Google документ, и Google не несет ответственности за его содержание. Он субъективный, и написан сотрудником для сотрудников.

Советы для инженеров

15 апреля 2013
Отредактировано 21 мая 2014
Переведено 31 августа 2015
Gretta Bartels, Software Engineering Manager at Google

Уважаемый читатель,

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

Один из моих более опытных коллег научил меня тому, что для менеджера очень важно быть предельно предсказуемым. У менеджера должен быть какой-то набор простых правил, о которых знают все его подчиненные, и которым они могут следовать даже когда менеджера рядом нет. Поэтому моя цель – чтобы программисты в моей команде могли задать сами себе вопрос “Что бы на это сказала мой менеджер?”, и сами себе на него правильно ответить. Тогда команда сможет работать практически самостоятельно, без моего руководства. А я буду сидеть дома и кушать пирожные :).

Вот список моих основных правил:

Кадр из Top Gear: USA (серия 2)

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

Практически с самого начала в качестве реализации ассоциативных массивов мы использовали Judy. У неё есть C-интерфейс и множество преимуществ. Мы даже используем обёртку для PHP, так как в версиях PHP до 7.0 Judy сильно выигрывает по количеству потребляемой памяти по сравнению со встроенными мапами.

Однако время идёт, и с момента последнего релиза Judy прошло немало лет – самое время посмотреть на альтернативы.

Меня зовут Марко, я – системный программист Badoo в команде «Платформа». Мы с коллегами провели небольшое исследование в поисках альтернатив Judy, сделали выводы и решили поделиться ими с вами.

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

Я использовал хеширование по алгоритму Robin Hood с ограничением максимального количества наборов. Если элемент должен быть на расстоянии больше Х позиций от своей идеальной позиции, то увеличиваем таблицу и надеемся, что в этом случае каждый элемент сможет быть ближе к своей желаемой позиции. Похоже, такой подход действительно хорошо работает. Величина Х может быть относительно невелика, что позволяет реализовать некоторые оптимизации внутреннего цикла поиска по хеш-таблице.

Если вы хотите только попробовать её в работе, то можете скачать отсюда. Либо пролистайте вниз до раздела «Исходный код и использование». Хотите подробностей — читайте дальше.

Светлана Шаповалова, редактор «Нетологии» адаптировала заметку Quincy Larson, в которой он представил три возможных пути становления веб-разработчика: для фронтенда, бекэнда и DevOps.

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

• Скорость
• Простота установки и настройки
• Цена (желательно бесплатно и с открытым кодом)
• Обмен информацией в формате JSON (по HTTP)
• Масштабируемость (возможность распределения на несколько серверов)
• Индексация в режиме реального времени
• Multi-tenancy (гибкость в настройках под индивидуального пользователя)
• Возможность переноса системы в облако

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

Протокол Modbus довольно распространен как в промышленных системах автоматизации, так и сетях систем типа "Умный дом", автоматизации малых объектов (теплицы и т.п.) и стыковки различного оборудования с домашним компьютером. Появление таких проектов как Arduino и Raspberry Pi значительно повысило интерес к задачам, связанным с робототехникой, автоматикой и автоматизацией. Все это обеспечивает рост популярности Modbus среди любителей и профессионалов. В статье рассмотрен вопрос тестирования и наладки, как отдельных устройств, так и сетей на базе протокола Modbus с позиции требований к программному обеспечению для решения таких задач и обзора существующих инструментов.

«Универсальный язык» нейронной сети Google Neural Machine Translation (GNMT). На левой иллюстрации разными цветами показаны кластеры значений каждого слова, справа внизу — смыслы слова, полученные для него из разных человеческих языков: английского, корейского и японского

За последние десять лет система автоматического перевода текстов Google Translate выросла с нескольких языков до 103, а сейчас она переводит 140 млрд слов ежедневно. В сентябре сообщалось, что разработчики приняли решение полностью перевести сервис Google Translate на глубинное обучение. У этого подхода есть много преимуществ. Перевод становится гораздо лучше. Более того, система может переводить тексты на языки, для которых никогда не видела переводов, то есть не обучалась специально для этой языковой пары.

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

Почитав на сайте http://arduino.cc и посабирав информацию на разлинчых форумах, узнал о возможности прошивать Pro Mini при помощи других плат Arduino.

Привет, Хабр! Под катом пойдёт речь о реализации свёрточной нейронной сети архитектуры InceptionV3 с использованием фреймворка Keras. Статью я решил написать после ознакомления с туториалом "Построение мощных моделей классификации с использованием небольшого количества данных". С одобрения автора туториала я немного изменил содержание своей статьи. В отличие от предложенной автором нейронной сети VGG16, мы будем обучать гугловскую глубокую нейронную сеть Inception V3, которая уже предустановлена в Keras.

Вы научитесь:

1. Импортировать нейронную сеть Inception V3 из библиотеки Keras;
2. Настраивать сеть: загружать веса, изменять верхнюю часть модели (fc-layers), таким образом, приспосабливая модель под бинарную классификацию;
3. Проводить тонкую настройку нижнего свёрточного слоя нейронной сети;
4. Применять аугментацию данных при помощи ImageDataGenerator;
5. Обучать сеть по частям для экономии ресурсов и времени;
6. Оценивать работу модели.

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

Всем привет. Несколько месяцев назад мы вместе с victorzs решили сделать простой и удобный профилировщик c++ кода (подразумевается профилирование времени исполнения участков кода, функций).


Скриншот профилирования примера из SDK CryEngine

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

• Профилировать выбранные участки кода
• Работать на нескольких платформах
• Учитывать переключение контекста
• Требовать минимальных дополнительных затрат памяти во время профилирования
• Не накладывать дополнительных временных ограничений во время выполнения приложения. Согласитесь, если профилировщик будет работать дольше, чем профилиуремый кусочек кода, то можно сделать некорректные выводы.

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

Если вы хотите знать, сколько времени работает ваш код, и иметь при этом объективные доказательства — прошу под кат, где я покажу, как использовать профилировщик.

Одна из основных функций десктопного клиента Облака Mail.Ru — синхронизация данных. Ее целью является приведение папки на ПК и ее представления в Облаке к одинаковому состоянию. При разработке этого механизма мы встретились с некоторыми, с первого взгляда, достаточно очевидными особенностями различных файловых и операционных систем. Однако если о них не знать, можно столкнуться с довольно неприятными последствиями (не получится загрузить или удалить файл). В этой статье мы собрали особенности, знание которых позволит вам правильно работать с данными на дисках и, возможно, убережет от необходимости срочного хотфикса.

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

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

Привет, Хабр! Последнее время все больше и больше достижений в области искусственного интеллекта связано с инструментами глубокого обучения или deep learning. Мы решили разобраться, где же можно научиться необходимым навыкам, чтобы стать специалистом в этой области.

Если разделять языки программирования по популярности, то они делятся на три эшелона. Первый эшелон включает мейнстрим-языки, такие как Java, JavaScript, Python, Ruby, PHP, C#, C++ и Objective-C. Несмотря на то, что некоторые из ведущих языков возможно увядают, вам лучше знать один или несколько из них, если вы хотите иметь возможность легко найти работу.

Языки второго эшелона пытаются пробиться в мейнстрим, но ещё не добились этого. Они доказали свою состоятельность путем создания сильных сообществ, но они до сих пор не используются большинством консервативных IT-компаний. Scala, Go, Swift, Clojure и Haskell — языки, которые я бы отнёс ко второму эшелону. Некоторые компании используют эти языки для отдельных сервисов, но широкое применение встречается редко (за исключением Swift, который начинает обгонять Objective-C в качестве основного языка для iOS). Go и Swift имеют хорошие шансы на переход из второго эшелона в первый в течение ближайших двух-трёх лет.

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

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

Когда, за бутылкой пива, я заводил разговор о нейронных сетях — люди обычно начинали боязливо на меня смотреть, грустнели, иногда у них начинал дёргаться глаз, а в крайних случаях они залезали под стол. Но, на самом деле, эти сети просты и интуитивны. Да-да, именно так! И, позвольте, я вам это докажу!

Допустим, я знаю о девушке две вещи — симпатична она мне или нет, а также, есть ли о чём мне с ней поговорить. Если есть, то будем считать это единицей, если нет, то — нулём. Аналогичный принцип возьмем и для внешности. Вопрос: “В какую девушку я влюблюсь и почему?”

Можно подумать просто и бескомпромиссно: “Если симпатична и есть о чём поговорить, то влюблюсь. Если ни то и ни другое, то — увольте.”

Определение 1. Однородный контейнер – это такой контейнер, в котором хранятся объекты строго одного типа.

Определение 2. Неоднородный контейнер — это такой контейнер, в котором могут храниться объекты разного типа.

Определение 3. Статический контейнер — это контейнер, состав которого полностью определяется на этапе компиляции.

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

Определение 4. Динамический контейнер — это контейнер, состав которого частично или полностью определяется на этапе выполнения.

По такой классификации, очевидно, существуют четыре вида контейнеров:

1. Статические однородные

   
   
   Сможете придумать пример?

   Обычный массив — int[n].

   
   

2. Статические неоднородные

   
   
   Примеры?

   Наиболее яркий пример такого контейнера — это кортеж. В языке C++ он реализуется классом std::tuple<...>.

   
   

3. Динамические однородные

   
   
   Догадались?

   Правильно, std::vector<int>.

   
   

4. Динамические неоднородные

   
   

   Вот об этом виде контейнеров и пойдёт речь в данной статье.

   
   

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

Проект Tagsistant позиционирует свое творение, tagfs, как следование за общей тенденцией. Интернет шаг за шагом пытаются переводить на семантические рельсы, а файловые системы, считают авторы проекта, закоснели в устарелых принципах — иерархия, директории, вот это всё.
И в принципе, я с ними в чем-то согласен. Представьте, что у вас есть несколько сотен фотографий, одни из которых сделаны в Кёльне, другие сделаны на закате, на третьих изображены девушки, а четвертые сделаны в 2010 году. Теперь вообразите, что вы хотите выполнить следующую операцию: получить список фотографий, которые сделаны на закате в Кёльне с вашей подругой, исключая те, которые были сделаны в 2010 году.
Да, возможно, скажет кто-то, можно ведь создать директории, например, Koeln, sunset, girls, 2010, потом рассовать в них софтлинки на файлы… Как-то так, но разве это предоставит необходимую гибкость и удобство в составлении запросов (хотя бы в решении приведенного выше примера)?
Да, можно попытаться воспользоваться EXIF-тегами. Но камера не указывает в них присутствия девушек на фото и других критериев, ограниченных вашей фантазией. А если речь вообще не о фотографиях, а об отчетах?
Можно попытаться писать своеобразные теги в атрибуты файлов, используя ext4, при помощи setattr\getattr — по крайней мере, я видел такое предложение в вопросе тегирования файлов, не пробовал. Но это тоже половинчатое решение, даже если будет работать.
Реальный пример для затравки, который я могу придумать, исходя из моих потребностей. У меня есть папка с огромным количеством разного картиночного хлама, когда-либо сохраненного в Downloads и позже протегированного (на самом деле, не одна). Я хочу получить из всего этого мусорного полигона список фотографий форумчан-девушек, которые сделаны в Киеве, содержат изображения пива и сделаны раньше 2012 года. Вместе с ними я хочу получить изображения всех админов форума, которые у меня есть:

$ ls ~/tagsistant/store/forum/girls/beer/=Kyiv/time:/year/lt/2012/+/admin/@/

Как мы уже рассказывали в предыдущих постах, прежде, чем создать PTYSH мы попробовали всё мы протестировали множество систем управления проектами и задачами, чтобы выбрать хорошие идеи для собственной разработки. Была проделана не просто колоссальная, а титаническая работа, результат которой обидно просто так забыть, тем более, что выбор системы управления проектами нередко ставит в тупик самых искушённых руководителей. Ещё сложнее выбрать систему для web-студии. Вы спросите: «Так это, вы что, создали кучу аккаунтов и протестировали все эти системы за меня?»

Одна и та же история повторяется снова и снова. Сначала команду людей озаряет идея.

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

Но что же здесь не так? Почему для многих стартапов это оборачивается проблемами?