Сегодня, 13 ноября, Международный день слепых. Он приурочен ко дню рождения педагога Валентина Гаюи, который в 1784 году открыл на личные средства первую в мире школу для незрячих детей. Это не праздник, а памятная дата, призванная напоминать обществу о существовании рядом людей с нарушениями зрения. В современном мире большая часть жизни людей переместилась в on-line, что открыло перед людьми с ограничениями здоровья новые возможности, но и породило новые вызовы.



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

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

Когда вы используете приложения на node.js в продакшене, вам приходится задумываться о стабильности, производительности, безопасности и удобстве поддержки. Данная статья описывает мои мысли о лучших практиках использования node.js в бою.

К окончанию данного руководства вы получите систему из 3 серверов: балансировщик (lb) и 2 сервера приложений (app1 и app2). Балансировщик будет следить за доступностью серверов и распределять между ними траффик. Серверы приложений будут использовать комбинацию systemd и кластеризации node.js для балансировки траффика между несколькими процессами ноды на сервере. Вы сможете выкатывать код с помощью одной команды со своей машины, и при этом не будет перерывов в обслуживании или необработанных запросов.
Все это можно представить в виде схемы:

Вступление

Не так давно, а именно двенадцать месяцев назад, начался мой последний год аспирантуры на физическом факультете ВУЗа под названием University of California, Davis. Вставал законный вопрос — что делать дальше? За преподаванием, движением науки и прочими развлечениями год пройдёт очень быстро. Решать надо было заранее. Основной план был найти позицию постдока, причем где-нибудь в Токио, Рио де Жанейро или Сингапуре, так что вроде как и путешествуешь, а вроде как и работаешь. И по идее под это дело у меня всё было подготовлено: и статьи, и знакомые, и знаний в определённых областях физики конденсированных сред — на троих. Я начал активно гуглить сайты разных вузов, в интересующих меня географически частях мира, написал научно ориентированный CV, подписался на рассылки где публикуются вакансии постдоков, намекнул всем знакомым, что если что — то мне надо сказать в первую очередь. Я даже по скайпу с какими то профессорами общался на тему работы в их научных группах. В общем всё куда-то катилось.

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

1. Аспирант — $27k
2. Постдок — $45k
3. Профессор — $117k

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

От переводчика: данная статья написана Дядюшкой Бобом в августе 2012 года, но, на мой взгляд, вполне актуальна до сих пор.



За последние несколько лет мы видели целый ряд идей относительно архитектуры систем. Каждая из них на выходе давала:

1. Независимость от фреймворка. Архитектура не зависит от существования какой-либо библиотеки. Это позволяет использовать фреймворк в качестве инструмента, вместо того, чтобы втискивать свою систему в рамки его ограничений.
2. Тестируемость. Бизнес-правила могут быть протестированы без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего компонента.
3. Независимоcть от UI. Пользовательский интерфейс можно легко изменить, не изменяя остальную систему. Например, веб-интерфейс может быть заменен на консольный, без изменения бизнес-правил.
4. Независимоcть от базы данных. Вы можете поменять Oracle или SQL Server на MongoDB, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не связаны с базой данных.
5. Независимость от какого-либо внешнего сервиса. По факту ваши бизнес правила просто ничего не знают о внешнем мире.

Диаграмма в начале этой статьи — попытка объединить все эти идеи в единую эффективную схему.

Привет, представляю твоему вниманию перевод статьи Моники Динкулеску '<input> I ♡ you, but you're bringing me down'. Художественный перевод с английского не является моей основной специализацией, поэтому в тексте возможны неточности. Правки призываю отправлять личным сообщением, а если есть что сказать, велкам в комментарии. Отдельное спасибо @Kt за редакторские правки. Приятного чтения.


Некоторые люди делают мебель. Некоторые люди вяжут. Некоторые люди имеют хобби, которые никак не пересекаются с HTML спецификациям из 90-х. Но я не из таких. И, вот история о том, как <input> стал той хренью, которой он является, и почему его надо сжечь

Ранние годы

1995 был клевым годом. Друзья, Скорая Помощь, Зена по телеку. TLC занимали верхушки чартов с хитом "Waterfalls". С браузерами было нормуль, потому что HTML было все очень нормуль. У нас были Mosaic, Netscape и IE1, а при утверждении спеков HTML 2, наконец, выкроили время для стандартизации форм. Девяносто пятый был годом рождения <input>, и теперь, когда он достаточно взрослый, чтобы покупать в магазине алкоголь, нам нужно поговорить.

С приближением Web 3.0 все активнее начинают использоваться подходы API first и Linked Data (или что-то вроде Sematic Web). В связи с этим читателям предлагается познакомиться с фреймворком для удобного создания API на базе схем собранных на schema.org с генерацией ответов в виде JSON-LD,

Это укороченная версия туториала Api-platform

Предлагаю читателям «Хабрахабра» перевод статьи «Zombie Code When Maintainability Goes Out Window».

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

Да, скажешь ты? Почему?

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

Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

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

А где-то под этим лесом находится манхетен

Многие боятся переходить с «мускуля» на «посгрес» из-за того, что лишь смутно понимают, что это даст. Некоторых останавливает мысль, что наверно Postgres — это слишком сложная база и требует обучения. А также, что возможно чего-то придется лишиться в связи с переходом. Попробую немного прояснить ситуацию.

Как вы могли заметить, у нас тут затишье. Но наш творческий поиск не прекращается, и первая октябрьская публикация будет посвящена ACO (Ant Colony Optimization)



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

Дизайн, как и мода, подвержен регулярным переменам. Но всё же есть направления, которые никогда не теряют свою популярность. Одним из них является минимализм. В последние годы бурно развивались HTML 5, CSS 3 и ряд других технологий, позволяющие сегодня создавать очень сложные веб-страницы. Тем не менее, минимализм в дизайне всё ещё очень востребован.

В конце августа после серии бесплатных лекций на Data Science Week 2015, организаторы решили провести двухдневный дататон (datathon) – соревнование, где команды программистов и аналитиков решали бизнес-задачи из области Data Science.

На дататоне было три задачи, две из которых подготовила команда HeadHunter и одну компания OZON. Это было, сразу скажу, не самым простым заданием, потому как большая часть наших данных конфиденциальна. Никто не захочет, чтобы программисты и аналитики упражнялись на реальных резюме или закрытых данных по вакансиям. Но кое-что мы все же собрали. Для проверки результатов организаторы придумали метрики и написали чекеры. А победили на дататоне эти ребята:



Прямо здесь и сейчас я предлагаю вам испытать свои силы и решить три задачи, с которыми ребята бились на дататоне. Чекеры для проверки и все файлы прилагаю.

Если вы программист (или чего хуже архитектор), то можете ли вы ответить на такой простой вопрос: как писать НЕ тестируемый код? Призадумались? Если с трудом можете назвать хотя бы 3 способа добиться не тестируемого кода, то статья для вас.

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

Допустим, я создал браузерную игру, а что дальше? Если для мобильных — есть магазины Google Play, App Store, Windows Store и куча всяких альтернативных. Можно найти площадки для распространения сборок standalone — Desura, Steam, Itch.io. Но когда задумываешься о судьбе браузерки, то невольно впадаешь в ступор. И куда ее?

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

Уже около полугода я пишу на ES6 (который в итоге назвали ES-2015) и ES7, с использованием бабеля в качестве транслятора. Писать мне приходилось в основном серверную часть, соответственно, использование модулей было само собой разумеющимся: до ES6 — с помощью модульной системы самой ноды, а теперь — с помощью стандартизированной семантики самого языка. И мне захотелось написать статью, в которой расписать тонкости, плюсы, подводные камни и необычности новообретенной модульной системы языка: отчасти — чтобы другим было проще, отчасти — чтобы разобраться во всём окончательно самому.

Я разберу, что такое модуль, как происходит экспорт сущностей, как происходит импорт сущностей, чем система модулей ES6 отличается от системы модулей в NodeJS.

Для тех, кто хочет погрызть гранит IT-науки, мы продолжаем публиковать список камней повкуснее и пополезнее. Предлагаем вашему вниманию следующую часть списка рекомендуемой литературы, рассчитанной для студентов 3 семестра Технопарка.

Предыдущие части: первая, вторая.

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

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