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

• «Программирование на КОБОЛе калечит мозг, поэтому обучение ему должно трактоваться как преступление». («The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense».)
   
• «Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации». («It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration».)

Дейкстра умер 6 августа 2002 года. Сегодня, спустя десять с небольшим лет после его смерти, мы вправе оглянуться вокруг и спросить себя: а насколько изменились обстоятельства? Иными словами: а сейчас (в наши дни) среди широко употребляемых языков программирования есть ли такие языки, использование которых влечёт для склонных к ним программистов почти неминуемый риск заметной профессиональной деформации?

Как мне кажется, они есть; и это прежде всего те языки, которые подпадают под определение write-only language, то есть поощряют написание такого исходного кода, прочтение и понимание которого слишком трудно, неоправданно трудно (как правило, даже труднее, чем его написание автором кода), хотя в нормальных языках должно быть наоборот.

Наиболее употребительным из таких языков является Perl.

Будьте покойны: я не намерен просто ткнуть пальцем в Perl и объявить, что он плох. Это вышло бы слишком малоубедительно без доказательств и подробностей. И именно поэтому прямо сейчас на примере, взятом из жизни, я покажу вам четыре механизма, при помощи которых Perl воздействует на сознание программиста и поощряет сочинение им такого кода, который оказывается неприглядным write-only.

Предисловие

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

Поиски

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

Первым делом я решил посмотреть не оправился ли node-inspector, который после перехода на node.js 0.6.x перестал поддерживать профилирование CPU и Heap. Оказалось, что в новой версии node-inspector неработающий профайлинг окончательно исключён и теперь это просто debugger. Немного покопавшись в коде старой версии, мне всё же удалось завести профилирование CPU и Heap на node 0.8.x, однако это решение не было идеальным. Чтобы вывести его из состояния «поделки» необходимо было бы заменить устаревший интерфейс WebKit-консоли на современный, переписав приличное количество кода и исправить некоторые проблемы производительности. В целом, решение на основе консоли WebKit мне кажется очень не гибким, поэтому я бросил эту затею и продолжил поиски.

Вот оно

За годы участия в разработке ПО, я вывел для себя 3 правила, пересечение которых дает нужный результат: Делать правильные вещи правильно и быстро. Любопытно взглянуть, как Scrum нам помогает достигать эти цели?

Введение

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

На днях столкнулся с задачей:

Сделать две одинаковые по высоте -колонки, не зависимо от количества текста в какой либо из них.

Условия:

1. Никаких таблиц;
2. Поддержка IE6+ и т.д;
3. Резиновая верстка;
4. Никакого JavaScript, чистый HTML и CSS.

Дизайн:

В дизайне изображены две колонки с отступом друг от друга. Каждый из них имеет свой фон и border с округленными уголками. На вид все просто.

Поиск решений:

Искал и естественно нашел очень полезный пост, где описаны все самые действенные способы решения данной задачи: http://habrahabr.ru/post/64173/.
Собственно 4-е решение из этого поста было наиболее приемлемым, но с помощью него мне так и не удалось вывести два разных фона для своих колонок.

Решение

Сегодня корпорация Google в своём блоге проекта Chromium представила новый JavaScript-бенчмарк — Octane. Суть этого нового теста состоит не только в оценке синтетической мощности движка, но и в боевых условиях. Для этого замеряется производительность движка в реально использующихся js-библиотеках, не считая стандартных для Google V8 Benchmark тестов, таких как Richards или Delta Blue. Далее краткое описание новых тестов и несколько замеров.

Оригинальный текст — что-то вроде сборника ссылок с минимальным комментарием и картинкой. Я постарался немного дополнить статью, поэтому это теперь не совсем перевод, а скорее «расширение» оригинала. P. S. Да простят меня уважаемые читатели за немного издевательские хабы.

Такое чувство, что люди уже запустили веб-сервер на основе всего, до чего только добрались их руки. Ниже список нескольких очень нестандартных подходов к выбору железа для сервера.

Spud: Веб-сервер, работающий на электричестве из картофеля

Нужны какие-нибудь комментарии? По-видимому они столкнулись с проблемой гниения картофеля.

Эксперимент на данный момент официально закончен, так как у автора сгнила картошка. Сейчас Spud просто Самый Энергоэффективный Веб Сервер в Мире, который работает от одной ААА батарейки (которая будет питать его еще несколько лет). Графы напряжения/силы тока больше не обновляются и сервер не будет доступен из Интернета до тех пор, пока однажды у автора не появится провайдер, который позволит это сделать.

Идея и реализация: жмем в SublimeText2 сочетание клавиш, получаем панель со списком build-вариантов, автоматически сформированным по файлу выбранной Build System, выбираем нужный вариант и наблюдаем как непосредственно в интерфейсе Sublime Text 2 отображается процесс сборки проекта.

Сразу скажу, что здесь я делюсь своим бесценным опытом совместной разработки плагина ProjectBuild для Sublime Text 2, потому что в результате только опыт и был получен, поскольку, как оказалось, необходимости в реализации данного плагина не было, и весь этот процесс оказался изобретением велосипеда. Печально, но опыт все же бесценен. Повествование будет таким, что о «велосипеде» будет сказано только в конце.

В предыдущем посте я описал, что this в javascript не привязывается к объекту, а зависит от контекста вызова. На практике же часто возникает необходимость в том, чтобы this внутри функции всегда ссылался на конкретный объект.
В данной статье мы рассмотрим два подхода для решения данной задачи.
1. jQuery.proxy — подход с использованием популярной библиотеки jQuery
2. Function.prototype.bind — подход, добавленный в JavaScript 1.8.5. Рассмотрим также его применение для карринга (частичного применения функции) и некоторые тонкости работы, о которых знают единицы.

Сегодня в зарубежных блогах появилась занятная новость о необычном поведении браузеров: на днях Chris Coyier, автор сайта css-tricks.com показал, как классу можно дать больший приоритет, чем id. Нужно всего лишь применить к объекту 256 классов!

Это адаптативный перевод статьи. Оригинал находится по ссылке: «10 Signs of a Trustworthy Website».

В Интернете находятся миллионы сайтов. Надежность некоторых из них не вызывает сомнений: к примеру, если речь идет об Интернет-магазине Macy’s или о новостном портале BBC. Но сколько раз в поисках определенного продукта или сервиса вы сталкивались с компаниями, о которых никогда раньше не слышали? И сколько раз вы задумывались: безопасно ли иметь с ними дело?

Можно поспорить, что в большинстве случаев вы принимали решение, опираясь исключительно на сайт компании как таковой. Вы не звонили друзьям и не читали отзывы на сайтах типа Yelp (хотя это может быть очень полезным). В конечном итоге, просмотрев сайт, вы либо закрывали его в поисках другого ресурса, либо принимали решение о покупке продукта или заказе услуги – ведь так? Я сам делал так не один раз.

Почему? Чем мы руководствуемся?

Случайно наткнулся, был сильно удивлен:

True Color GIF image
(32697 colors, 184565 bytes)

Доброго времени суток, коллеги. В этой статье я опишу опыт создание многопоточного загрузчика файлов (с ограниченной нагрузкой на сервер) на JS (jQuery).

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

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

В пятой редакции ECMAScript был представлен строгий режим (далее в статье Strict Mode). Strict Mode накладывает слой ограничений на JavaScript, он отгораживает вас от опасных частей языка (те части, которые есть исторически, но лучше чтобы их не было) и позволяет снизить вероятность ошибки.

Пока читал эту статью я написал 38 тестов, покрывающих все правила Strict Mode, объявленные в спецификации ES5. Вы можете посмотреть насколько ваш браузер поддерживает эти справила вот тут.



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

Firefox 4 уже полностью поддерживает Strict Mode, а Chrome 11 практически полностью. Strict Mode уже не за горами — давайте изучим его подробнее!

По просьбам некоторых читателей решил написать топик про контекст в javascript. Новички javascript часто не понимают значение ключевого слова this в javascript. Данный топик будет интересен не только новичкам, а также тем, кто просто хочет освежить данный аспект в памяти. Посмотрите пример ниже. Если вы затрудняетесь ответить на вопрос «что будет выведено в логе» хотя бы в одном из пунктов или хотите просто посмотреть ответы — добро пожаловать под кат.

var f = function() {
    this.x = 5;
    (function() {
        this.x = 3;
    })();
    console.log(this.x);
};

var obj = {x: 4, m: function() {
    console.log(this.x);
}};


f();
new f();
obj.m();
new obj.m();
f.call(f);
obj.m.call(f);

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

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

• скорость jsperf (тест с прекомпилированными шаблонами: jsperf)
• расширяемость := кастомные контролы, трансформация шаблонных данных
• data bindings
• компиляция в json для дальнейшего кэширования
• приятный синтаксис (без мешанины логики и структуры)

Из недостатков:

• шаблонные данные могут находиться только в атрибутах и литералах (хотя, поверте — этого достаточно)

Если тема интересная —

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

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

Я не изобретатель очередного велосипеда марсохода, а просто хочу рассказать про python фреймворк WEB2PY. На Хабре почему-то нет каких-либо статей про этот чудесный инструмент. Если интересно, под хабракатом небольшая история использования web2py и его описание.

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