Привет. Меня зовут Иван Мельничук, я Head of Development Department в украинской IT-компании. В публикации хочу поделиться личными профессиональными подходами относительно решения вопроса legacy code в условиях стремительного развития проекта и рассказать о приемах, к которым прибегает наша команда в случаях “когда фичи нужно сдавать “на вчера”.

Разбираемся с проектом

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


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

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

Библиотека докладов

Это не просто статья — это целая библиотека докладов про внутреннее устройство тех или иных крупных и высоконагруженных проектов. Все эти доклады звучали на конференциях HighLoad++ и РИТ++ за последние несколько лет.

Я занимаюсь в Яндексе продуктовой безопасностью и, кажется, сейчас самое время подробнее, чем уже было на YaC, рассказать на Хабре о том, как мы внедряем TLS.

Использование HTTPS-соединений является важной частью безопасного веб-сервиса, так как именно HTTPS обеспечивает конфиденциальность и целостность данных на этапе передачи их между клиентом и сервисом. Мы постепенно переводим все наши сервисы только на HTTPS-соединение. Многие из них уже работают исключительно по нему: Паспорт, Почта, Директ, Метрика, Такси, Яндекс.Деньги, а также все формы обратной связи, имеющие дело с персональными данными пользователей. Яндекс.Почта уже больше года даже обменивается данными с другими почтовыми сервисами по SSL/TLS, поддерживающими это.



Все мы знаем, что HTTPS — это HTTP, завернутый в TLS. Почему TLS, а не SSL? Потому что принципиально TLS — это более новый SSL, при этом название нового протокола наиболее точно характеризует его назначение. А в свете уязвимости POODLE можно официально считать, что SSL больше использовать нельзя.

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

1 Один столбец вместо нескольких

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

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

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



Курс открывает моя лекция о том, зачем вообще автоматизировать процесс разработки. Из нее вы получите представление о то, что будут рассказывать мои коллеги.

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

Это перевод статьи с сайта «The SSD Review». По правде сказать, это не совсем перевод — скорее выжимка смысла с добавлением графиков, которые говорят сами за себя. Я намеренно оставил без внимания рекламу накопителей Intel. Ну и еще один момент — автор странно передергивает, сначала показывая преобладание random 4-8k write, а затем приводя на графиках как меру производительности random 4-8k read. Ощущение, что он сам что-то недоговаривает. Будет неплохо, если кто-то из компетентных людей оставит в комментариях свое мнение.

UPD:
Достоверность информации в статье подтверждена опытным путем. Проделал опыты, написал парсер и выложил результаты хабражитель deseven, за что ему огромное спасибо. Табличку с его данными вы можете посмотреть в конце статьи.

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

Итак, в чем же обман?

Многие из Вас слышали, что пару недель назад Google представил свою программу для Навигации.
Кто не видел- вот ссылка на видео
Но с этой программой была одна проблема… Она работала только в США.
Вероятно, лицензии на карты, купленные Google не позовляли использовать навигацию в других странах
(в США у Гугла уже свои карты ;-) )
Но, как мы знаем, мир не без добрых людей: Благодаря их стараниям, Навигация работает во всем мире, в том числе и в наших странах- сам только что катался с ней по Киеву:

Под катом- как этого добиться на Вашем телефоне под OS Android
P.S. Оригинал этого руководства взят с форума xda-developers

1. Переходим на страничку с нужным видео
2. В адресной строке заменяем Y (в слове youtube) на

Оригинал vasilisc.com/speedup_ubuntu

Пока осваивал Убунту, перечитал множества статей об ускорении Убунту, как в плане загрузки, так и работы вообще.

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

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

От переводчика: Это первая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Как клиентская, так и серверная часть Persona написаны на JavaScript. В ходе работы команда проекта создала несколько инструментов на все случаи жизни — от локализации до отладки, управления зависимостями и многого другого. В этой серии статей разработчики Mozilla делятся с сообществом своим опытом и этими инструментами, которые пригодятся любому, кто пишет высоконагруженный сервис на Node.js.

Первая статья цикла посвящена распространённой проблеме Node.js — утечкам памяти, особенностям утечек в высоконагруженных проектах и библиотеке node-memwatch, которая помогает найти и устранить такие утечки в Node.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Зачем заморачиваться?

Вы можете спросить, зачем вообще отслеживать утечки памяти? Неужели нет более важных дел? Почему бы просто не перезапускать процесс время от времени, или просто добавить памяти на сервер? Есть три причины, по которым устранять утечки всё-таки важно:

1. Возможно, вы не сильно переживаете об утечках памяти, но этого нельзя сказать о V8 (движок JavaScript на котором работает Node). Чем больше памяти занято, тем активнее работает сборщик мусора, замедляя ваше приложение. Так что в Node утечки напрямую вредят производительности.
2. Утечки могут привести к другим проблемам. Протекающий код может блокировать ограниченные ресурсы. У вас могут закончиться файловые дескрипторы или вы вдруг не сможете открыть ещё одно соединение с БД. Такие проблемы могут возникнуть задолго до того, как кончится память, но обрушат ваше приложение ничуть не хуже.
3. Рано или поздно ваше приложение упадёт. И это наверняка случится во время наплыва посетителей. Вас все засмеют и будут писать про вас гадости на Hacker News.

Каждый год мы обучаем под свои проекты и набираем в команду студентов. Хантим, конечно, не всех. «Мы на работу ходим, а нам деньги плотют» — это точно не к нам. За «звездами» тоже не охотимся. Ищем в первую очередь тех, кто хочет расти, развиваться, становиться «звездой», а мы можем им в этом помочь.

Одна из проблем нашего высшего образования в том, что в вузах учат много чему, и алгоритмам, и языкам программирования, и ООП, и даже паттернам проектирования. Но я еще ни разу не встречал, чтобы в вузах учили работать работу. Лабораторки не в счет. Спихнул – и забыл! Возможно, просто не везло.

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

Итак, про семь навыков…

Обрабатываете много данных в браузере?
Хотите отправлять их обратно на сервер?
Да так, чтобы отправлялось побыстрее и помещалось в один http запрос?

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

На последней конференции РИТ++ мне посчастливилось стать впервые докладчиком конференции такого масштаба и такой значимости. В этой статье я не просто хочу пересказать всё, о чём я докладывал. Выступать впервые перед такой большой аудиторией для меня было непривычно и я половину забыл рассказать, нервничал немного. Речь пойдет о создании с нуля собственной отказоустойчивой структуры для веб-проектов. Мало кому из системных администраторов дается возможность с нуля запустить в production крупный проект. Мне повезло.

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

Это позволяет избежать CSRF/XSRF-атак (подделки межсайтовых запросов).

Рассмотрим следующий пример: допустим у Google есть URL вида gmail.com/json?action=inbox, который возвращает 50 первых сообщений вашего почтового ящика в формате JSON. Злоумышленник, чей сайт находятся на другом домене, не может выполнить AJAX запрос, обратившись по данному URL, чтобы получить данные, ввиду same origin policy (правило ограничения домена). Но ничто не мешает злоумышленнику включить вышеуказанный URL на свою страницу с помощью тега .


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

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

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

При работе с Amazon многое остается за кадром. Для обычного пользователя это даже хорошо, ему нужен работающий сервис и не имеет значение, как этот сервис реализован. Но для тех, кто проектирует системы для Amazon или других облачных провайдеров это может быть проблемой. Некоторые внутренние аспекты работы выясняются при общении с тех. поддержкой, но в большинстве случаев для лучшего понимания приходится проводить различные тесты и эксперименты.
Возьмем, к примеру, производительность сети. Гарантирует ли Amazon определенную пропускную способность сети для любой машины или нет, как зависит скорость сети от ресурсов сервера, от региона или времени суток. Скажу сразу, что поддержка Amazon настоятельно рекомендует использовать машины больших размеров, если скорость сети является важным критерием и то, что максимально скорость 1G/s. Но всё всегда лучше проверить на практике.

Здравствуйте.

Этот топик открывает цикл статей по использованию системы управления конфигурацией Puppet.

Что такое система управления конфигурацией?

Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете ОС (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфиги ваших любимых текстовых редакторов (nanorc, vimrc), выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.

Привет!

Вчера я написал статью о производительности EBS. Оказалось, что наиболее производительным будет RAID 10 из EBSoв. Помимо того, что RAID быстрее, это ещё и экономически более выгодно. Минимальная стоимость в месяц EBS диска с 2000 IOPS (минимальный размер 200 GB)

200 * $0.125 + 2000 * $0.10 = $225

Тот же объём информации в 200 GB в RAID10, состоящий из 8 стандартных EBS по 50 GB:

8 * (50 * $0.10) = $40

Исходя из расчётов, RAID дешевле более чем в пять с половиной раз.

Привет!

Вы используете утилиты командной строки для управления серверами и сервисами AWS? Как же надоело обновлять и качать их из разных мест. Да и неоднородность команд тоже не радует…

AWS официально выпустили консолидированный CLI, который в последствии будет включать в себя все доступные сервисы. А сейчас можно управлять

• Amazon Elastic Compute Cloud (Amazon EC2)
• Elastic Load Balancing
• Auto Scaling
• AWS CloudFormation
• AWS Elastic Beanstalk
• Amazon Simple Notification Service (Amazon SNS)
• Amazon Simple Queue Service (Amazon SQS)
• Amazon Relational Database Service (Amazon RDS)
• AWS Identity and Access Management (IAM)
• AWS Security Token Service (STS)
• Amazon CloudWatch
• Amazon Simple Email Service (Amazon SES)