Честно скажу, когда я искал работу, мое резюме смело можно было отнести к категории плохих. Да, там было несколько хороших секций (типа, а вот я написал 2 книжки и 30 статей), но также там была и таблица скилов со строчкой: C#, 1 year of experience, Intermediate (!).

Сейчас я читаю много резюме и приглашаю людей на интервью. За последние 3 года я провел около сотни интервью, а резюме повидал раз в 5 больше. Так что сейчас я довольно четко представляю, что я хочу видеть в резюме. Но для начала я расскажу, чего в резюме я видеть не хочу.

Шаблоны

Многие аутсорсинговые компании придумали себе шаблоны резюме. Мотивация, в принципе, понятна, они хотят все унифицировать чтобы использовать machine learning для извлечения хороших кандидатов все выглядели одинаково, как рядовые в строю. Однако, шаблоны эти одинаковы для всех позиций и составлены мудрыми CTO недалекими HR, которые понятия не имеют, что такое реально классный программист.

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

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

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

Что же это за проблемы?

Awesomium — это библиотека, для интеграции браузера на базе Chromium в своё приложение. Вся прелесть Awesomium состоит в том, что его можно интегрировать в приложение практически любого типа (есть примеры интеграции в 3D игры на базе Unity3D), он обладает широким набором возможностей для разработчика и, честно говоря, с ним просто приятно работать.

Но, к сожалению, библиотека имеет довольно скромную документацию, практически отсутствуют примеры и комюнити (это касается разработки под C++, дотнетчикам повезло больше). Некоторые моменты мне приходилось по крупицам собирать с разных источников, а к другим понимание приходило после серии проб и ошибок.

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

Документация по Ангуляру отлично подходит для начала работы и ковыряния в API. Однако, она не объясняет как организовать и управлять приложением, когда оно разрастется до десятков или сотен тысяч строк кода. Я собрал здесь некоторые из моих наблюдений и передового опыта по управлению расползающимися приложениями. Сначала взглянем на организацию, затем перейдем к некоторым советам по улучшению производительности и закончим краткой сводкой по инструментам, серверам и процессу сборки. Этот пост будет сосредоточен на больших приложениях, в частности, есть отличная статья по лучшим практикам AngularJS с декабрьской встречи, на которую также стоит взглянуть.

Ни для кого не секрет, что e-mail маркетинг только начинает набирать обороты во всем мире. А для России – это ещё и вовсе молодая ниша на рынке. И профессиональная верстка электронных писем здесь один из составляющих факторов успеха. Под профессиональной версткой понимается не только визуально красиво и надежно сверстанный макет, но и то, как выглядит usability открытки с маркетинговой точки зрения, как оптимизирована графика вместе с типографией для спам-фильтров и многое другое. Верстка электронных писем довольно обширная тема, в одной статье все не уместить, поэтому в данном посте постараюсь описать только базовые элементы и приемы, надежно проверенные за годы практики и работающие в top самых используемых почтовых клиентах мира: iPhone 4S/5; Outlook 07/10/13; iPad; Apple Mail; Android 2.3/4.0; Yahoo; Gmail. Если рассматривать только российский рынок, то нельзя не упомянуть о Mail.ru и Яндекс.Почта.

Что нужно знать в начале?

Сразу хочу выделить несколько из основных и важных моментов:

1. В нашем арсенале имеется очень урезанный набор css-свойств, которые поддерживаются всеми почтовиками. При этом, стили нужно прописывать inline, а в head выносить только вендорные свойства и те блоки объявлений, которые не несут нагрузки на основную стилизацию письма. Ну и использовать link in head — крайне нежелательно.
2. Не используйте background-image в основных визуальных элементах дизайна и не помещайте в изображения важную текстовую информацию. Вообще нужно всегда учитывать такой вариант, что письмо будет просматриваться получателем без единого изображения.

Каркас

Пожалуй каждый, кто хоть раз верстал письмо под рассылку, знает, что каркас лучше строить с помощью таблиц. На самом деле простая блочная модель div поддерживается на данный момент во всех перечисленных выше почтовиках, за исключением MS Outlook начиная с 2007 версии. Это связано с тем, что в качестве движка последние версии Outlook используют Microsoft Word, который в свою очередь много не знает о блочных css-свойствах. Игнорировать при верстке данный почтовый клиент я не рекомендую, поэтому в качестве фундамента все же используйте table. Да и добившись хорошего результата для Outlook, можно быть уверенным, что в большинстве почтовиках, письмо будет смотреться тоже хорошо, а скорее и лучше.

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

Как только я узнал об исполняемых PHP-архивах phar, сразу же захотелось их попробовать. Разработчиками, да и на хабре, это добро было довольно неплохо разрекламировано. Была информация о том, что использование архивов +APC даёт прирост производительности в 6 раз.

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

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

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

Чтобы не тратить ваше время я распишу свойства, о которых я хотел бы вам рассказать:

• функция counter
• функция calc
• функция attr
• функция toggle
• единица измерения — rem
• единица измерения — vw
• единица измерения — vh

Намедни наткнулся на замечательное высказывание талантливого боксера и невероятно сильного человека Роя Джонса. Он сказал: “Нужно работать так, словно таланта у тебя вообще нет”. Эти слова невероятно глубоко запали мне в душу. Я перечитал фразу раз двадцать и с каждым новым прочтением все больше понимал — “Да! Точно! Это именно то, чего мне не хватало.”

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

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

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

Диспозиция: проект полностью пишется «нашей» командой с нуля в течении полугода. В этот момент по инициативе заказчика решено начать делать регулярные (раз в две недели) ревью кода и вообще проверить проект на соответствие их стандартам кода, архитектуры и идеологии. Стоит отметить, их специалисты представлены не сферическими техническими начальниками в вакууме, а вполне адекватными программистами синьор уровня из США (не Индия, заметьте), которые пишут свои проекты параллельно с нашим.

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

3500 иконок готово. Можно сказать спасибо. После выпуска 3000 иконок FatCow прошел почти год, страницу посетило 700к посетителей. Пошел пятый год рисования. Находить удачные метафоры становится сложнее. Пытаемся охватить набор метафор, который нужен для специфичного софта и узконаправленных сайтов.
Чтобы дойти до 4000 иконок, работы хватит до апреля 2014 года. Потом укрупняем палитру или уходим в 5000. То есть по многочисленным запросам пользователей помимо 16-го и 32-го размера намерены освоить 48x48 и 96x96. В таком случае до середины 2015-го года нарисуем первую «крупную» тысячу.



Пятилетку за четыре года, кота за день. Чтобы понять, какие именно 500 метафор было положено в основе дополнительной эмиссии, смотрим сотканный kreol2013 надстройкой над программой KhodeN «ковер»…

Месяц назад вышла четвертая версия фреймворка Foundation от компании Zurb, достойной альтернативы Twitter Bootsrap.
В данной версии делался упор на мобильные устройства. В компании считают, что дизайнеры должны ориентироваться в своей работе в первую очередь на мобильные устройства, а после уже на декстопы.

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

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

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

Памятка

Как отсеять хостинг провайдеров

1. Используется ли виртуализация серверов в принципе?
2. Используется ли виртуализация систем хранения данных или виртуализация сетей? Это необязательные требования, но они свидетельствуют о технологическом уровне облачного провайдера.
3. Как управлять услугами? Есть ли портал самообслуживания? Можно ли самому запускать новые серверы, управлять производительностью уже запущенных? Можно ли добавить диски, настроить внутреннюю адресацию и управлять маршрутизацией? Можно ли самому настраивать расписание резервного копирования и запускать задания по восстановлению данных? И т.д.
4. Как учитываются ресурсы? Есть ли автоматизированный биллинг (посекундный-почасовой)? Или все учитывается руками?

Площадка

1. Где расположен ЦОД: за границей или в РФ? Насколько далеко от вашего офиса и второго ЦОДа, если он есть? Задержки?
2. Кому принадлежит ЦОД? Можно ли войти посмотреть?
3. Он сертифицирован? Какие были аварии на этой площадке ранее?
4. Какие провайдеры связи присутствуют на площадке?
5. Как можно будет подключиться к «облаку»?

Услуги «облака»

1. Что такое vCPU (виртуальное ядро)? Чему оно равняется: целому физическому ядру процессора или, например, его четверти?
2. Какие используются дисковые ресурсы? Локальные или подключенные по SAN?
3. Как резервируются каналы до Интернет?
4. Что делать, если стандартного функционала «облака» не хватает? Можно ли, например, подключить к «облаку» специализированное сетевое оборудование или машины не x64 архитектуры и так далее?
5. Доступен ли гибридный режим работы? Как сделана интеграция в этом случае?
6. Есть ли сервис резервного копирования?
7. Как средства ИБ доступны в базе, какие нужно отдельно заказывать?
8. При необходимости построения HA (high availability) или DR (disaster recovery) решений возможно ли разнести части размещаемого ИТ-сервиса между двумя ЦОД? Есть ли у провайдера второе облако для построения подобных решений?

Поддержка

1. Отвечает ли поддержка 24/7, быстро и по делу, а не «мы разберёмся позже»?
2. Язык — русский и английский?
3. Как далеко можно выходить за SLA, если очень нужно? (Как правило, на Западе — ни шагу в сторону).
4. Нужно ли обращаться в поддержку за мониторингом ресурсов и баланса, или все данные доступны через портал самообслуживания?
5. Есть ли демо-режим? Насколько он отличается от «боевого» и чем конкретно?

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

Многие из вас наверняка заметили, что я пишу книгу о Zend Framework. Недавно я закончил черновики двух глав: «Архитектура приложений на Zend Framework» и «Понимая Zend Framework». В первой главе объясняется архитектурный шаблон Model-View-Controller (MVC) и причины, по которым он стал стандартом де-факто для веб-приложений. Во второй исследуется связь MVC с компонентами Zend Framework, их структурой и взаимодействием.

Завершив обе главы я осознал, что большую часть времени описывал модель и ее фактическое отсутствие в Zend Framework. На самом деле ни один веб-фреймворк не предлагает нам полноценную модель (по причинам, которые я объясню чуть позже). И ни в одном из них не дается внятного объяснения этому обстоятельству. Вместо этого они последовательно связывают понятие модели с родственным, но не идентичным понятием доступа к данным, что изрядно всех запутывает.

Эта сторона фреймворков никогда не привлекала особого внимания. И все же именно она лежит в основе целого класса проблем в тех приложениях, которые пытаются использовать MVC по образу и подобию фреймворков для веб-приложений. Более того, попытки донести идею модели до других разработчиков нередко напоминают битье головой о стену. Я не хочу сказать, что все разработчики тупые или не понимают саму идею, просто никто из них (вне зависимости от того, работают они с PHP или нет) не связывает модели с той областью, которая наделяет их смыслом — принципами объектно-ориентированного программирования.

Ночи доброй всем текущим и утра пятничного всем, кто в пятницу начинает рабочий день с Хабра…
Снова я.
Вот, выбрался, вернее сказать — чутка урвал часок от сна на тему: надо маленько написать (да и с умыслом шкурным тоже), как дела обстоят и как оно идет вообще по моей разработке. Для тех, кто не в теме, далее ссылки на предыдущие статьи:
Часть№1: habrahabr.ru/post/124427
Часть№2: habrahabr.ru/post/138874
Часть№3: habrahabr.ru/post/150196
Часть№4: habrahabr.ru/post/156573

Ну, а кто уже в теме — продолжим.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Идея информационной телепортации крайне проста: специальный сканер разбирает объект на атомы, одновременно считывая их полное состояние. Полученные данные передаются в пункт назначения, где 3D-принтер с атомарным разрешением печатает исходный объект. Просто, логично, понятно. Многократно показано в фантастике (например, в фильме «Трон»).
Какова же должна быть пропускная способность сети для комфортной телепортации? Хватит ли нам плохонького 3G от «большой тройки»?

А еще говорят что крепостное право России отменили в 19 веке. Не верьте, это не так. История о контрастах в условиях работы в иностранной и российской компаниях, экшена разработки на java/GWT, лжи коллеги и поведения Директора, наслаждающегося своим всемогуществом и вседозволеностью, не подкрепленное законодательно.



Началось эта история когда заканчивался проект на прошлой работе. Все было солидно: крупная международная компания, коммандировки в США и Англию, стабильность и легкая скука из-за большого количества рутины на проекте. Никаких авралов, отлично выстроенный процесс разработки, отдельная QA команда и автоматизированные регрешен тесты, иностранный менеджмент за пару лет работы ни разу не повысивший голос ни на кого в комманде, проджект менеджер спокойно переносивший функционал в следующие релизы, когда не успевали с разработкой и тестированием. Отличный коллектив профессионалов, каждому можно было доверять и знать что в трудный момент помогут. Атмосфера дружбы, когда приятно приходить на работу и общаться. Но всему хорошему и спокойному всегда приходит конец :( И дальше как полоски у зебры, в моей жизни появилась новая полоса…

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

• Данные хранятся в AWS S3
• Сам FTP-сервер (выбран был Pure-ftpd) должен быть максимально возможно доступен
• Организовать балансировку нагрузки (опционально)