Месяц назад я писал про наше участие в хакатоне по открытым данным.

После хакатона мы не остановились на достигнутом, как это обычно бывает, а продолжили работу. У нас на руках оказались данные, к которым раньше имели доступ, наверное, только сотрудники Министерства образования: результаты ГИА и победы на олимпиадах за 2014-2015 год для 90% московских школ. Для 55% школ удалось собрать данные по ЕГЭ за 2015 год. Прокачали все аккаунты московских школьников в Контакте, посмотрели, какие ВУЗы они указывают у себя в профайлах после окончания.

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

• Баллы по ЕГЭ по гуманитарным предметам выше, чем по техническим. История — исключение;
• Естественно-научные дисциплины посередине.

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

Хочу поделиться нашим opensource-решением для генерации docx документов, которое позволяет заполнять документы по шаблону, оформление которого можно менять в Word без переписывания кода.

Для начала — немного вводных.

Что нам было нужно от шаблонизатора

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

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

Мы наблюдаем бум свободных проектов. В основном, благодаря Гитхабу. 23 декабря 2013 года на сервисе был создан 10-миллионный проект. К 23 декабря 2015 года количество проектов более чем утроится: прямо сейчас на Гитхабе 28 миллионов проектов.

Многих привлекает идея свободности, потому что она перекликается с идеей «улучшения мира», как основной мотивации продуктивной деятельности человека.

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

Судя по последним вопросам на Тостере, у людей много ожиданий, но мало понимания в этой области. Поэтому я решил написать это эссе.

Само по себе выкладывание проекта не является улучшением мира

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

Вы выложили код. Чем вы помогли экономике в этот момент? Ничем, поэтому и миру вы пока ничем не помогли.

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

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

Синергетический эффект свободного кода

Кто, если не ты? Когда, если не сейчас?



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

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

Только автоматизация. Только PowerShell.

Предисловие

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

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

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

Внимание: PowerShell вызывает привыкание.

Вот типичная форма подключения к вай-фаю. Она вообще-то на огромной странице с кучей иероглифов, но серая подложка помогла мне понять, что это и есть самая важная форма подключения, а остальное — справка и реклама.



Иконки важны. Судя по ним, галочка внизу — это, почти наверняка, «я согласен с условиями». Телефон вверху — наверняка номер. Дальше — замок — это пароль. Оба поля активные, то есть логин и пароль у меня должны быть сразу, так?

Нет, нифига, китайский UX подразумевает, что я сначала введу телефон и нажму оранжевую кнопку (цвета иконки — и да, это кнопка!). Получу пароль и введу его во второе поле, а потом нажму зелёную кнопку. Робот сравнит телефон с паролем и пустит меня дальше. Эту форму, скорее всего, рисовал китаец.


^{А это обычная такая телефонная будка раннего космического века}

Сейчас покажу ещё несколько вещей, рождённых в стране, где квалифицированных инженеров примерно раз в двадцать больше, чем в Америке, а состояние изобретательности «советского инженера» ещё не пройдено. Я, конечно, опять продолжу свою историю и покажу интерфейсы в реальном мире — они не менее интересны с точки зрения юзабилити, нежели HCI, и не менее полезны для понимания, как можно работать с пользователем.

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

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

Важные замечания:

• Пункты с неуказанным источником написаны мной самостоятельно. Поправьте меня, если вы заметите какие-то неточности. Предложите лучшую аналогию, если это возможно.
• Заголовки ссылаются на соответствующие им статьи в Wikipedia. Пожалуйста, читайте эти статьи для более серьезных и детальных объяснений.
• Аналогии — отличный способ объяснить материал, но они не идеальны. Если вы хотите по-настоящему понять перечисленные концепции, вам следует начать с фундаментальных азов и рассуждать, исходя из них.

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

Говорят, метатеги для целей SEO мертвы и больше нет смысла прописывать заветную строку meta keywords. Действительно, в современных многофакторных алгоритмах этот тег потерял свой вес. Но это вовсе не значит, что нужно отказываться от работы с семантическим ядром сайта — оно по-прежнему бесценно для структурирования сайта, формирования тематики (которой и интересуются поисковики) и даже для контекстной рекламы. Собрать ядро — задача не из лёгких, собрать его с умом и не превратить в «накидайте мне синонимов» — ещё сложнее. Так вот, в статье пойдет речь о макросах и формулах MS Excel, которые упростят обработку больших семантических ядер. Представляем вам небольшого Excel-робота от нашего изобретательного и не жадного специалиста отдела контекстной рекламы RealWeb Дмитрия Тумайкина. Ему и слово.

Кто работал с онлайн-рекламой, тот в цирке не смеётся знает, что поисковики порой выдают неожиданные ответы на запросы или подкидывают совершенно не те объявления, которые могут быть интересны. В последнем случае корень проблемы зачастую кроется в наборе ключевых слов, которые использует рекламодатель в своих кампаниях. Бездумная автоматизация подбора ключевиков приводит к печальным последствиям, среди которых самое удручающее — пустые показы и клики. Excel-изобретатель и рационализатор Realweb Дмитрий Тумайкин озадачился этой проблемой и создал очередной файл-робот, который рад раздать миру и Хабру. Вновь передаём слово автору.

Предлагаю вашему вниманию перевод статьи «Responsive Upscaling: Large-Screen E-Commerce Design» автора Christian Holst.

Революция в адаптивном дизайне не за горами (если уже не случилась!), и даже не смотря на то, что интернет-магазины не взялись на адаптивный дизайн столь же агрессивно, как другие индустрии, все же это становится популярным.

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

1. Только 18% из 50 ведущих американских интернет-магазинов, которые мы тестировали ранее, в этом году адаптировали свой дизайн под большие экраны (в то время как у 94% этих сайтов дизайн адаптирован под мобильные устройства).
2. Почти три четверти электронных продаж все ещё совершаются на ПК, а не на мобильных устройствах (смотрите здесь, здесь и здесь).
3. Около трети этих пользователей приходят с экранов шире 1350 пикселей (смотрите здесь, здесь и здесь). (Примечание: Разумеется, есть разница между шириной экрана и шириной браузерного окна — реальное число пользователей с браузером указанной ширины будет ниже. Мы рекомендуем вам отслеживать размеры браузерного окна в вашей веб-статистике для более полной картины того, насколько значителен этот сегмент для вашего сайта.

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

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

И вообще вели себя вызывающе с точки зрения ИТ.

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

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Уже 3 с лишним года занимаюсь дизайном и версткой почтовых рассылок, которые ориентированы на англоязычных пользователей. За время работы перелопатили огромную кучу информации, перепробовали много вариантов верстки, набили достаточное количество шишек. Были найдены и исправлены типичные баги, которые в той или иной мере повторялись во всех почтовых клиентах. Также нашлись проблемы с некоторыми CSS свойствами — различные почтовые клиенты интерпретировали их по разному. Каждое письмо тестировалось на самых популярных почтовых клиентах: Gmail, Outlook, Yahoo, Android, iOS, MozillaThunderbird, Microsoft Outlook, The Bat. Рассылки ходят на сотни миллионов пользователей и приносят очень хорошие результаты. Итак, приступим к изучению.

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

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

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

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

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

Во всем мире все больше людей начинает пользоваться смартфонами, растет число владельцев таких устройств и в России — в Москве девайсами пользуется уже больше половины всех сотовых абонентов. При этом лидерами по продажам в нашей стране являются Samsung и Apple. В США у двух главных мобильных платформ почти равенство — 47,7% у iPhone, 47,6% у Android, в Европе Android впереди, а в Японии наоборот, на iOS приходится более 60% продаж.

Этот общемировой тренд приводит и к тому, что более половины всех писем теперь открывается с мобильных устройств. А значит, дизайнерам, которые занимаются подготовкой почтовых рассылок, необходимо сделать так, чтобы сообщения хорошо выглядели и на Android-устройствах, и на iPhone.

Написание данного поста навеяно недавней поистине шикарной работой, Niсole Merlin. Во многом ее методика верстки схожа с моей и мне радостно от того, что это направление развивается теперь и на западе. Чем же этот способ так хорош? Все очень просто. Не нужно объяснять как важно адаптировать под мобильные платформы сверстанные письма для того, чтобы они были прочтены. Читать простыни на телефоне мало кто будет. Что же все это время делал западный разработчик? Он верстал табличной версткой с элементами блочности, затем причесывал этот код медиазапросами для поддержки мобильников. Чем этот подход ущербен? А тем, что ни на андроиде, ни на яблоке медиазапросы не поддерживаются следующими почтовыми клиентами: Gmail, Yandex, Mail.ru. По большому счету западные коллеги могли бы и наплевать на яндекс с мейлом, но вот Gmail как ни крути первый среди почтовиков.



Для Nicole Merlin это стало очевидно и она разработала свою методику, которая основывается на резиновой верстке с минимальным использованием медиазапросов(progressive enhancement) и это работает! Но немного не так как хотелось бы нам в России. Вся резиновость автора держится на inline-block элементах и оперированием max-width. Но вот беда-то, наши ребята из яндекса и мейла max-width не поддерживают. Сначала я расскажу об отличиях моего подхода от приемов Nicole, а затем плавно перейду к своим мыслям и примерам кода, которые стоит использовать при подготовке писем.