Всем привет!

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

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

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

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

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

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

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

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

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

Продолжая тему JIT-компиляции .NET'a, сегодня мы рассмотрим диспетчеризацию методов у интерфейсов, generics (как классов, так и отдельных методов вместе с реальными сигнатурами); производить отладку релизных сборок с оптимизациями; разберемся с истинным предназначением типа System.__Canon (это не то, что Вы подумали).

Готовил я как-то тесты для системы, один из модулей которой помимо всего остального вычислял значение хеш-функции для загружаемого файла. В ТЗ был прописан и необходимый алгоритм — ГОСТ Р 34.11-94. За эталон я взял значение хеша, посчитанного сторонней утилитой Rhash.

f86c9ecfb6e63726b35ebc79528d013d52b781e06e29d7eb0c9d1cb256efb7c1

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

964ba8755ca782ec3c5e0f98c93347f9b96d9f39cf5c7fdef43a23273fe8868a

Кто не прав — разработчик модуля или утилиты?

Введение

Алгоритмы нечеткого поиска (также известного как поиск по сходству или fuzzy string search) являются основой систем проверки орфографии и полноценных поисковых систем вроде Google или Yandex. Например, такие алгоритмы используются для функций наподобие «Возможно вы имели в виду …» в тех же поисковых системах.

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

• Расстояние Левенштейна
• Расстояние Дамерау-Левенштейна
• Алгоритм Bitap с модификациями от Wu и Manber
• Алгоритм расширения выборки
• Метод N-грамм
• Хеширование по сигнатуре
• BK-деревья

А также проведу сравнительное тестирование качества и производительности алгоритмов.

Cколько времени я использую GitFlow и Semantic Versioning, меня все не покидает чувство, что чего-то в них не хватает. Обе концепции хороши, но так как они предлагают решения для проблем из разных областей, их совместное использование выглядит сложнее, чем должно быть.

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

В одном из своих проектов мне потребовалось распознавание символов и мой выбор остановился на tesseract ocr. На Хабре уже была подобная статья, но на данный момент она не актуальна, во время установки не получилось в точности повторить инструкции автора. В данной статье рассказывается о процессе установке Tesseract OCR под MinGW.

Я работаю разработчиком БД (MS SQL) и большая часть моей работы, это написание кода на T-SQL. Работая в Query Analyzer, а затем в Management Studio (2005, 2008, 2008R2) мне очень сильно не хватало функций редактора и дополнительных функций среды разработки, направленных именно на процесс написания кода, построения запросов и т.п… По сравнению с MS Visual Studio или Embarcadero RAD Studio, что мог предложить Query Analyzer? Изменить отступ блока кода, изменить регистр выделенного текста, закомментировать и отменить комментирование блока кода, перетащить название таблицы или поля (полей) в окно редактора, заскриптовать выбранный объект. А ведь так не хватало полноценного IntelliSense. Всех этих удобных функций по автодополнению, интерактивных подсказок к набираемому коду, выбор из списка объектов и т.п.

С выходом MS Management Studio 2005 ситуация не изменилась. И только в MS Management 2008 появился Transact-SQL IntelliSense. Да, появилось автозавершение набираемого слова, предоставление списка объектов БД и полей таблицы, подсветка синтаксических пар (begin… end, ()). Но уже до этого я стал пользоваться сторонней утилитой SQL Assistant от SoftTree Technologies. На фоне возможностей, которые предоставляет SQL Assistant родной IntelliSense просто дубовый. А разве можно получить что-то большего, ведь это SQL, а не объектно-ориентированный язык? Можно! В этой статье я хотел бы рассказать об утилите SQL Assistant, а точнее о функция и приемах, которые я использую при написании SQL-кода.

NAT (Network Address Translation) обладает массой достоинств, но и не лишен недостатков, например, необходимости конфигурировать проброс портов (port forwarding) в случае если мы хотим иметь доступ к серверу, который находится за NAT раутером. Существует несколько способов прохождения через NAT (NAT traversal). В данной статье я попробую рассмотреть один из них, который основан на UDP hole punching (буквально — пробитие дырки с помощью UDP, прошу прощения за кучу терминов на английском, но я просто не знаю как их благозвучно воспроизвести по-русски).

Привет, %username%!
Пользуешься неофициальными bitcoin клиентами? Есть повод присмотреться к ним повнимательней.
После реализации бэкдора для RSA мне стало интересно, как обстоят дела с остальными криптографическими примитивами. Оказывается, целая наука под названием клептография занимается передачей информации в так называемых «подсознательных» каналах. Таких, о которых никому не известно кроме отправителя и получателя. Вроде стеганографии, только внутри криптоалгоритмов.

Есть такой очень хороший товарищ по имени Daniel Julius Bernstein. Математик, программист и спец по компьютерной безопасности. Его хэш CubeHash чуть не дотянул до третьего раунда SHA-3, а потоковый шифр Salsa20 попал в шорт лист проекта eStream. А еще он автор культовой в узких кругах криптобиблиотеки NaCl, о трех штуках из которой я бы хотел вкратце рассказать.

Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов.
Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды.

Vim — мощный текстовый редактор, у которого большая аудитория. Хотя программе более 20 лет, её функциональность продолжают улучшать через скрипты vimscript. Последняя версия свободного редактора Vim 7.4 вышла в августе 2013 года.

Проблема в том, что за два десятилетия Vim разросся до страшных размеров: около 300 000 строк кода на C89. «Очень мало людей могут понять этот код или имеют смелость изменять его. Есть проблема и с добавлением нового кода и патчей в Vim: единственный мейнтейнер не успевает за развитием экосистемы плагинов», — пишет бразильский программист Тиаго де Арруда Падилья (Thiago de Arruda Padilha), который создал проект Neovim — обновлённую и улучшенную версию Vim для 21 века.

Привет, Хабр!
Сегодня я расскажу и покажу вам, как можно использовать всю мощность ваших видеокарт для игр перебора паролей к Wi-Fi. Как-то не комильфо в наше время использовать только процессорные мощности под эти задачи (в частности aircrack-ng), когда в 80% компьютеров есть видеокарта. Поэтому разумно использовать всю потенциальную мощность ваших систем. А именно, речь пойдет о замечательной программе pyrit.

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

Новости хаба .Net на Хабре занимают 33 страницы или 328 постов. Что говорит о том что новости появляются почти каждый день =) Посмотрим на самое интересное из них (на мой скромный взгляд). Ну и загляните под кат: до ката, конечно же, не все.

Доступен новый JIT: теперь с поддержкой SIMD
Как работает декомпиляция в .Net или Java на примере .Net
Microsoft раскрыла исходный код компилятора С#
Consulo: ~1000 коммитов, или как прошла осень
Под капотом у Stopwatch
Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

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

В компьютерных науках для эффективной реализации очереди с приоритетом используются структуры в виде кучи.

В начале 20-го века проводилась активное изучение всего региона Антарктики, и разные страны отправляли экспедиции в эту зону. В 1914 году была отправлена и экспедиция, названная отрядом Моря Росса — соответственно региону, куда направлялся отряд. Экспедиция была не особенно удачной, по большей части из-за неправильной организации и оснащения. Результаты этой экспедиции не стоило бы описывать сейчас, если бы не случайная находка 22 необработанных негативов того времени.

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

— Ложась спать программист ставит рядом на столик 2 стакана.
— Один с водой — если захочет пить, второй пустой — если не захочет.

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

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

Disclaimer. Сейчас программистов много. Хороших и разных. Я буду писать про хороших. И то, не про всех, а про большую часть из тех, с кем имел честь вместе разрабатывать ПО.

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

void SomeMethod(IEmployee lazyguy)
{
    if(lazyguy == null) throw new ArgumentException(“lazyguy”);
    // Do something with lazy guy. Fire him, for example.
}

Кто-то пытался превратить это в:

void SomeMethod(IEmployee lazyguy)
{
    UniversalValidator.CheckNotNull(lazyguy);
    // Meet with him and talk about motivations
}

Кто-то превращал это во что-то похожее. Однако у всех, я могу поспорить, оставался осадок что что-то тут не так. Красивее было бы как-то по другому. А что в итоге? Огромное количество велосипедов с квадратными колесами! Как сделать по-другому?

Update: Статья и скрипты были обновлены в марте 2013 (прошло 5 лет, старые скрипты не сильно отличаются от текущих, но всё-таки лучше изучать актуальный код, а логика загрузки системы за эти годы немного изменилась — иначе работает udev, появились новые синтетические fs вроде devtmpfs, /var/run переехал в /run, etc.).

Когда я осваивал Linux, мне было очень интересно что происходит при загрузке системы. Попытка разобраться в процессе загрузки привела меня в исходники загрузочных скриптов (/etc/inittab, /etc/rc*, /etc/init.d/*, ...) и их конфигов (/etc/sysconfig/*, /etc/cond.f/*, ...). Надо отметить серьёзные размеры и сложность этих скриптов — чтобы в них разобраться потребовалось немало времени. Но я в те времена искренне верил, что загрузка это сложный процесс, и что размеры и сложность загрузочных скриптов вполне оправданы.

Когда меня окончательно достал RedHat (2001 год), я решил собрать свой дистрибутив на базе LFS. Для своего дистрибутива пришлось самостоятельно разрабатывать загрузочные скрипты, и тут-то выяснилась правда: ничего сложного в процессе загрузки нет!

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