Привет Хабр!

Изначально хотел назвать статью «HTML по ГОСТ`у», но потом выяснилось что у большинства программистов не было предмета «Метрология и стандартизация» и о «стандартизации», «сертификации», «унификации» не все слышали.

В i-Free я много занимаюсь разработкой веб-приложений. А поскольку их много, они разные и работают в разных условиях, то само собой приходится задумываться о стандартизации. Есть такой проект «Пуленепробиваемый HTML5» (http://html5boilerplate.com/), в котором разработчики решили создать идеальный шаблон странички. Он мне очень нравился, и все свои проекты я начинал именно с него. Но, исправляя баг за багом, делая все новые и новые приложения, я пришел к выводу, что многого в нем не хватает. В этой статье я хотел бы рассказать о том, что обычно пропускают при написание страничек и веб-приложений и показать, чем и зачем я прокачал свой шаблон пустой странички.

В интерфейсе каждой операционной системы существует такое понятие, как область уведомлений.

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

Рич Хикки произноситит классные, дающие пищу для размышления выступления. Считается, почти всем, если не поголовно, программистам надо их услышать и увидеть. Если вы не интересуетесь Clojure, лучше смотреть с конца.

• Are We There Yet? – 2009 -размышления о том, правилен ли текущий подход к реализации ООП. Обсуждается много вопросов о проектировании Clojure.

Восходящее проектирование в ФП. Идея — основа хорошего дизайна. Антипаттерны в Haskell.

Немного теории

В прошлой части мы построили высокоуровневую архитектуру приложения. Мы определили подсистемы и их связи, а также разделили программу на три слоя: Application, Game Logic, Views. По логике, следующий этап — дизайн приложения. По важности этот этап не уступает предыдущему, так как именно в ходе дизайна мы должны поддержать все функциональные требования, определить фактическую структуру подсистем, описать основные технические проблемы, применить какие-либо типовые решения или придумать другие. Но прежде попробуем ответить на вопрос: каков он, хороший дизайн ПО? По каким критериям мы определяем «хорошесть» дизайна?

Для управления зависимостями в проекте, node.js, как и многие другие платформы, предоставляет собственный пакетный менеджер — npm. И несмотря на то, что он внешне похож, например, на Ruby Gems, и вроде бы выполняет те же самые функции, npm обладает некоторыми особенностями, которые стоит учитывать при разработке приложений на node.js. Одна из таких особенностей — это способ хранения директории node_modules в проекте. Многие, по аналогии с другими системами, оставляют в проекте только package.json с зафиксированными версиями модулей, а node_modules добавляют в .gitignore. Такая стратегия не всегда верна, если мы обратимся в FAQ на npmjs.org, то увидим там следующее:

Q: Стоит ли хранить node_modules в git?
A: Mikeal Rogers очень хорошо ответил на этот вопрос:
http://www.mikealrogers.com/posts/nodemodules-in-git.html
tl;dr

• Храните node_modules в git для проектов, которые требуется разворачивать, таких как вебсайты и приложения.
• Добавляйте node_modules в .gitignore для библиотек и повторно используемых модулей.
• Используйте npm для управления зависимостями в dev окружении, но не в скриптах используемых для деплоя.

Под катом перевод статьи Mikeal Rogers, в котором подробно описывается, с чем связан такой непривычный подход.

Учиться или не учиться? — вот в чем вопрос.
Как ни странно, ответ на него зависит от вашего личного взгляда на экономику. Не претендую на истину в последней инстанции, просто хотелось разобраться и внести некоторую ясность.

Всем привет!

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

Предыстория

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

В первую очередь, нам хотелось иметь ограниченный компактный набор конечных распространяемых модулей. Однако публичная сборка питона, распространяемая через python.org к этому не располагает, одна только стандартная библиотека, являющаяся неотъемлемой частью самого языка, состоит из более чем тысячи py-файлов. Именно поэтому, мы сразу обратили внимание на такую любопытную особенность интерпретатора, как возможность импорта модулей, находящихся в zip-архивах, когда все множество исходников на питоне, относящихся к одному или нескольким модулям, упаковано в zip-архив и распространяется одним zip-файлом.

19 августа 2009 года, в 12:30 Том Леман написал первую строчку кода задуманного им проекта Rap Genius, посвященного трактованию рэп-текстов. А уже в 18:22 того же дня была готова первая версия веб-сайта. Менее шести часов потребовалось на то, чтобы создать сервис, куда сегодня каждый месяц заходят 40 миллионов новых пользователей, который привлек уже 17 миллионов долларов венчурных инвестиций, и вокруг которого недавно разгорелся интернет-скандал, разрешившийся в пользу проекта и сделавший его ещё более популярным.

В первый же день, разложив по полочкам песню Killa Cam в исполнении рэпера Cam’ron, Леман внедрил те функции, которые до сих являются самыми востребованными. Конечно же, мы были просто обязаны позвать его выступить на последней конференции Design+Startup, проходящей под патронажем фонда First Round. На этой встрече Леман поделился теми четырьмя словами, благодаря которым Rap Genius смог состояться.

«Первая версия Rap Genius была просто отвратительна. Но благодаря этой отвратительности я узнал секрет, как нужно делать вещи в интернете. Секрет простой: чем хуже, тем лучше».

Что же это значит на практике? Том Леман с удовольствием рассказывает нам об этом.

Добрый день, уважаемое сообщество!

Существует большое количество малых и «маленьких, но гордых» организаций, которые при всей своей простоте вынуждены пользоваться определенной IT инфраструктурой. Хочу поделиться с вами некоторыми выводами по внедрению в них свободного ПО (СПО) и Линукса, которые я вынес для себя на базе многолетнего положительного опыта в этой области.

Слепок типичного заказчика

Обычно существовавшее изначально положение вещей характеризовалось следующим:

1. Организации с количеством компьютеров от 1 до 50 предпочитали использовать проприетарные решения для ОС одной хорошо всем известной заатлантической конторы.
2. Денег на покупку лицензий всегда не было. Предпочитали использовать «пиратчину».

Давайте напишем Clojure-библиотеку для работы с реляционными БД. Заодно потренируемся в написании макросов, попробуем использовать протоколы и мультиметоды. Ведь нету лучшего способа узнать язык, нежели что-то на нем написать. Ну… или почитать, как написал кто-то другой.

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



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

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

Это достаточно вольный перевод статьи. Дело в том, что несмотря на конструкции в одну строчку, материал сложен для понимания.
Беря во внимание то, что в комментариях Прелюдия или как полюбить Haskell просили, чтобы код был понятный, я внёс достаточно ремарок, и, надеюсь, код будет понятен и тем, кто далёк от Хаскеля.

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

Странные петли — это запутанные категории, когда двигаясь вверх или вниз в иерархической системе, находишь то же самое, откуда начал движение.
Зачастую такие петли содержат само-референтные ссылки.
Например, подобной странной петлёй обладает рекурсивные акронимы: «PHP — PHP: Hypertext Preprocessor».
Ну, и на сегодняшний день наиболее загадочным словом, содержащим странные петли, является понятие «я».

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

Немецкий математик Лёб мигрировал в 39-м году ХХ-го столетия в Великобританию. Лёб, в частности, развивал математическую логику и миру прежде всего известен Теоремой Лёба. Это теорема развивала труды Гёделя о неполноте математики. Теорема Лёба о взаимосвязи между доказуемостью утверждения и самим утверждением, она гласит, что

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

Всю эту сложность высказывания можно записать символически:


Можно ли такую функцию написать на Хаскеле?! Можно! И всего в одну строчку!

«Только со смертью догмы начинается наука.»
// Галилео Галилей

«Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
// х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца

Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.

AutoCAD начала 80-х

Зум появился очень давно, на заре эры графических интефейсов, с первыми векторными редакторами.
Но с тех пор он не был использован почти нигде, кроме САПР и программ для работы с графикой. Про него вспомнили только когда появились мобильные устройства — на маленьком экране не умещались большие фотки и веб-страницы.
В мобильных интерфейсах зум стал вполне привычным и естественным и продолжает эволюционировать. Но на десктопе зум заброшен и, на мой взгляд, совершенно напрасно. Zoomable user interface (ZUI) даёт ряд преимуществ, позволяющих лучше решить актуальные задачи. Я решил описать эти преимущества по типам зума, с примерами.

Наблюдая за своими родителями-пенсионерами, а точнее за размерами их пенсий, я крепко задумываюсь о том, как обеспечить себе нечто оное в достойном меня размере. На государство в составе СНГ рассчитывать, похоже, не приходится. Значит, надо что-то делать самому! И начинать надо сейчас, пока мне 32 года, есть какой-никакой заработок и силы крутиться. Раньше были мысли, что я буду вечно молодым, вечно здоровым и все время что-то делать. Постепенно начинаю осознавать, что лет 20… 30 — и силы будут таять (или распыляться). Поэтому пару лет назад я начал понемногу что-то делать в этом направлении. Получил некоторый опыт, который может быть интересен уважаемому сообществу. Даже если для читателя вопрос пенсии сейчас звучит безумно абстрактно, то все равно рекомендую хотя бы пробежаться. Если бы я 5 лет назад почитал такой материал — я был бы уже существенно богаче!..
UPD: в статье добавил про смысл диверсификации, а то в комментариях много вопросов было…

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


В этом цикле статей я попытаюсь захватить часть этой простоты путем написания простого интерпретатора для обычного императивного языка IMP (IMperative Language). Интерпретатор будет написан на Питоне, потому что это простой и широко известный язык. Также, питон-код похож на псевдокод, и даже если вы не знаете его [питон], у вас получится понять код. Парсинг будет выполнен с помощью простого набора комбинаторов, написанных с нуля (подробнее расскажу в следующей части). Никаких дополнительных библиотек не будет использовано, кроме sys (для I/O), re (регулярные выражения в лексере) и unittest (для проверки работоспособности нашей поделки).

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

Предварительный анализ возможных улучшений раскладки ЙЦУКЕН

Не будем долго описывать традиционно упоминаемые недостатки стандартной раскладки ЙЦУКЕН: 50% всех нажатий производится указательными пальцами, причем часто несколько нажатий подряд производит один из них, а также значительная нагрузка на правый мизинец. Перейдем к характеристике следующего уровня — чередованию рук. По моему скромному мнению (и не только, как будет показано ниже), это важнейшая характеристика, влияющая на скорость набора, поскольку руки могут действовать независимо, а пальцы в пределах каждой руки двигаются в большей степени согласованно.

Давным давно был язык С. И были в нем 2 функции управляющие памятью — malloc и free. Но это было слишком сложно.
Посмотрел на это Бьёрн Страуструп и решил что нужно сделать все проще. И изобрел С++. В дополнение к malloc/free там появились new/delete, деструкторы, RAII, auto и shared указатели.
Посмотрел на это Гвидо ван Россум, и решил, что С++ тоже не достаточно прост. Он решил идти другим путем и придумал Python, в котором даже malloc и free нет.
А тем временем норвежские троли создали на С++ GUI-библиотеку Qt, которая упрощает управление памятью для своих объектов за счет того, что сама их удаляет, когда посчитает нужным.
Phil Thompson расстроился, что отличной библиотеки Qt нету для замечательного языка Python. И решил их объединить проектом PyQt. Однако, как оказалось, если скрестить разные парадигмы управления памятью, обязательно вылезут побочные эффекты. Давайте посмотрим какие…

Привет, уважаемые Хабро-читатели и SQL-писатели. Команда ХостТрекера хочет поделиться полезной утилитой для SQL разработчиков и администраторов.

Какую задачу решаем?

Нахождение зависимостей объектов в БД.
Поиск по строке в метаданных БД (хранимых процедурах, View, пользовательских функциях, определениях таблиц, индексах, ключах)