Пару недель назад в ИТ-отдел зашла сотрудница из опта и попросила доделать мелкую фичу к своему рабочему месту. Заявку вполне ожидаемо поставили в очередь.

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

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

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

Все вы знаете систему Git. Хотя бы слышали — это наверняка. Разработчики, которые пользуются системой, ее или любят, или ругают за сложный интерфейс и баги. Система управления версиями Git де-факто является стандартом в индустрии. У разработчика могут быть мнения о преимуществах Mercurial, но чаще всего приходится мириться с требованием уметь пользоваться Git. Как у любой сложной системы, у нее множество полезных и необходимых функций. Однако, до гениальной простоты добираются не все, поэтому существующая реализация оставляла пространство для совершенствования.

Простыми словами — мудреным приложением было трудно пользоваться. Поэтому в лаборатории Массачусетского Технологического Института взялись за улучшения и отсекли все «проблемные элементы» (ведь то, что для одного проблема, для другого легко может быть преимуществом). Улучшенную и упрощенную версию назвали Gitless. Её разрабатывали с учетом 2400 вопросов, связанных с Git и взятых с сайта разработчиков StackOverflow.

Команда авторов вычленила самые проблемные места в Git, включая две концепции staging и stashing. Затем они предложили изменения, призванные решить известные проблемы.

На этот раз «Мой круг» совместно с Cofoundit постарались узнать, как разработчики участвуют в стартапах: как с позиции сотрудника, так и с позиции основателя компании. Мы опросили более 3500 человек, пользователей «Моего круга» и «Хабрахабра». Более 90% опрошенных имеют свой аккаунт на «Моём круге» — это именно те ИТ-специалисты, которые откликаются на вакансии или размещают их на нашем сервисе.

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

Отчёт получился довольно большим, но, на наш взгляд, крайне интересным и познавательным. Скучные цифры оформлены симпатичной инфографикой.

‘Login’ или ‘log in’? Одно слово или два? Это достаточно распространенный вопрос среди тех, кто пишет на английском языке. Давайте разберемся, как же правильно.

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



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

Владимиру всё это только предстояло.

Всем привет! Буду краток: в обмен на пять минут вашего времени отдел PHP-разработки компании Лайв Тайпинг расскажет вам о собственном микросервисе для хранения и обработки загружаемых изображений. Он называется Hermitage. Его задача — представлять изображение в разных версиях согласно заранее заданным параметрам. Hermitage будет полезен в ситуациях, когда необходим автономный и масштабируемый сервер для хранения изображений и манипуляций над ними.

Юрий Насретдинов (youROCK, Badoo)

Расшифровка доклада Юрия Насретдинова на конференции HighLoad++ 2015. Юрий расскажет про то, как Badoo (крупнейшая социальная сеть для знакомств с новыми людьми) сделали практически идеально ровную балансировку нагрузки на нашем кластере. Передаём ему слово...

Чтобы обслуживать то количество пользователей, то количество реквестов в секунду, которые мы получаем, у нас около трех тысяч серверов, и на PHP-FPM конкретно приходится 70 тысяч в пике.

О том, как мы эти запросы распределяем по нашему кластеру, я расскажу.



Кратко — о чем я буду рассказывать. Во-первых, я расскажу, как «с высоты птичьего полета» устроен роутинг запросов на нашем сайте. Потом расскажу, какие, вообще, существуют алгоритмы балансировки; про то, как мы делали балансировку до того, как мы сделали автоматическую систему. Расскажу про эту автоматическую систему, ну и будут кое-какие выводы. Также хотел сказать, что эта система будет выложена в open-source после этого доклада.

Масштабирование базы данных через шардирование и партиционирование

Денис Иванов (2ГИС)

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

Немного расскажу о себе — я работаю в команде WebAPI в компании 2GIS, мы предоставляем API для организаций, у нас очень много разных данных, 8 стран, в которых мы работаем, 250 крупных городов, 50 тыс. населенных пунктов. У нас достаточно большая нагрузка — 25 млн. активных пользователей в месяц, и в среднем нагрузка около 2000 RPS идет на API. Все это располагается в трех датацентрах.

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

Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код

Цель этой публикации — поделиться опытом работы над проектом со сложной историей и тяжёлым наследием. После ухода из очередного т.н. «стартапа», я решил что хочу попробовать новых ощущений: enterprise, legacy, etc. Для этого взялся за работу над корпоративным приложением для транснационального концерна. Разработка на тот момент шла уже третий год, приложение пережило несколько поколений разработчиков, но стабильного релиза так и не было.

Полагаю публикация будет полезной:

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

Затрагиваемые в статье вопросы:

• Низкая компетенция разработчиков, и что с этим можно поделать?
• Какие аргументы убедительны в глазах заказчика для нефункциональных изменений в проекте?
• Почему работа аналитиков и QA очень важна с точки зрения разработки в частности и для проекта в целом?

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

Я уверен, что многим программистам знакома формула:


А уж тот, кто плотно работал с графикой, знает эти цифры буквально наизусть — как в былые времена эникейщики запоминали серийники Windows. Иногда коэффициенты округляют до второго знака, иногда уточняют до четвертого, но каноническая форма именно такая.

Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.

Формула растиражирована и процитирована в тысячах статей, форумных обсуждений и ответов на StackOverflow… Но дело в том, что единственно-правильное её место — на свалке истории. Использовать её нельзя. Однако же используют.

Но почему нельзя? И откуда же взялись именно такие коэффициенты?

Ник Бабич разработчик, UX/UI специалист написал заметку в блоге UX Planet про UX-дизайн кнопки: советы по созданию, типы и состояния. Наша команда выполнила перевод данной статьи



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

Советы по созданию кнопок

Кнопки должны выглядеть как кнопки

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

Привет, хабравчане!

Меня зовут Михаил Матросов, я технический менеджер в компании Align Technology. Сегодня я поработаю капитаном и немного расскажу об основах современного С++.

Работая над большим проектом, мне часто приходится смотреть чужой код и порой я вижу странное. А именно, многие даже вполне матёрые программисты на С++ могут не знать некоторых фундаментальных для языка вещей. Ну, это даже не слишком удивительно — язык такой.

Мне бы хотелось поговорить об этих основах и начну я со своей любимой темы. Будем говорить об операторах new и delete. А точнее, об их отсутствии. Я расскажу, как писать надёжный и современный код на С++ без использования операторов new и delete.

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

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


Изображение взято с сайта behappy.me

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

Предисловие

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

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

22-23 апреля 2016 года в четвёртый раз прошла конференция JPoint, в т.ч. уже в третий раз подряд в Москве. В конференции приняли участие более 1000 Java-разработчиков, на 4 параллельных треках было прочитано 48 докладов. Далее приводятся подробности о прошедшей конференции.

До выхода в Бразилию с нашим продуктом, мы знали только, что эта страна — родина языка Lua, которым мы делаем свои "модные" логи.


Распределение тем на португалоязычной, преимущественно бразильской, версии Stack Overflow (изначально вместо pt. в урле даже было br.)

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

Факт 1. У бразильских айтишников есть самобытные комиксы

Один из популярных комиксов называется “Жизнь программиста”, и по стилю похож на то, как если бы Дилберт был разработчиком.

TL;DR: Mandrill захотел поднять цены в 4 раза. Они нашли способ через интеграцию с MailChimp.

В феврале этого года, как гром среди ясного неба, пришло письмо от Mandrill о том, что с 27го апреля он перестаёт существовать как независимый сервис и теперь чтобы им пользоваться нужно будет интегрировать свой Mandrill аккаунт в платный аккаунт MailChimp. Именно платный, пусть даже и самый дешевый. Вот как выглядит ценник MailChimp:



Напомню, что раньше Mandrill был бесплатным для небольших проектов до 12.000 писем в месяц (около 400 в день). Сейчас же как минимум $20 + сколько напосылаешь писем.

«Три девицы под окном пряли поздно вечерком.»



Ну как пряли. Не пряли, конечно, а лайкали друг на друга. По условиям конкурса «мисс Салтан» девицы должны были выбрать меж собой лучшую.

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

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

Вот что там было:

• Алена получила 1 лайк от Софьи и 2 лайка от Варвары.
• Варвара получила по лайку от Алены и Софьи.
• А Софья получила 2 лайка от Алены и 1 от Варвары.

Царь взял лайки, покрутил гайки, постучал по колесам, пошмыгал носом, причмокнул губами, поскрипел зубами, сгонял в палаты и объявил результаты.

Наибольший вес лайков (7 баллов) получила Софья, но титул «мисс Салтан» достался Алене (15 баллов).


После объявления результатов девицы бросились обратились к царю с просьбой рассказать,- откуда взялись эти странные цифры?