JavaScript принято считать прототип-ориентированным языком программирования. Но, как ни странно, этим подходом практически никто не пользуется: большинство популярных JS-фреймворков явно или неявно оперируют классами.
В этой статье я хочу рассказать об альтернативном способе программирования на JavaScript, без использования классов и конструкторов — чистым прототипным ООП и особенностях его реализации на ECMA Script 5.

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

Представляем наш первый рейтинг востребованности специалистов.

	Предложений на одного кандидата	Выборка (# кандидатов)
JavaScript	4.13	46
iOS	3.087	23
QA	3.045	22
PHP	2.928	111
C++	2.717	53
Java	2.412	97
Android	2.321	28
Тимлид	2.138	29
Python	1.98	50
.NET	1.865	96
Менеджер проекта	1.091	22
Ruby	1	24

Данные по рынку труда в Киеве, на других рынках вероятно ситуация отличается. Но тендеции все равно интересны.

Мы продолжаем писать про проектирование сайтов и разработку интерфейсов. На этот раз выделили сразу 19 принципов построения интерфейсов. Эти принципы мы по крупицам собирали на протяжении последних 3х лет работы из разных книг, статей, исследований и, конечно, собственного опыта разработки интерфейсов.

Создание интерфейсов в проектировании больших сайтов – это самый объемный и один из самых важных этапов. Поэтому я отдельно решил выделить принципы и законы проектирования интерфейсов.

• Принцип KISS. От англ. «keep it short and simple». Интерфейс должен быть простой и понятный, задачи должны решаться минимальным числом действий, все должно быть понятно и очевидно.
• Не заставляйте думать. Нужно избегать сложных действий, которые заставляют пользователей думать.
• Убираем очевидное. Не стоит показывать очевидные элементы интерфейса, нужно сосредоточиться только на действительно необходимых вещах.
• Соотношение сигнал / шум. В каждом интерфейсе есть важные элементы (сигналы) и маловажные или даже бессмысленные для определенной части системы (шум), естественно, нужно концентрироваться на сигналах и избегать шума.
• Проверенное лучше модного. Не стоит цепляться за моду и делать что-то только потому, что так делают другие, лучше отдать предпочтение проверенным элементам интерфейса.

Здравствуй Хабр!

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

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

Прошло пол года и мои кастомные прошивки с успехом используются по всему миру.

В данной серии статей пойдет речь о том, как делать reverse программирование для Android, реализовывать патчи, твики и моды.

Разработчики, использующие Bundle Transformer, часто спрашивают у меня: «Какой минимизатор обладает самой высокой степенью сжатия?». В принципе, в сентябре прошлого года в своей статье «Вышел Bundle Transformer 1.6.2 или что изменилось за полгода?» я уже проводил сравнение минимизаторов по степени сжатия кода, но это сравнение было поверхностным и не было подкреплено цифрами.

В этой краткой статье мы проведем сравнение наиболее популярных алгоритмов минимизации CSS- и JS-кода на примере адаптеров-минимизаторов из Bundle Transformer. В качестве исходных файлов будут использоваться файлы bootstrap.css и bootstrap.js из Twitter Bootstrap версии 2.3.2. Измерять размеры файлов мы будем с помощью YSlow.

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

Не так давно был представлен Z-Wave модуль для Raspberry Pi — RaZBerry, который превращает мини-компьютер в полноценный контроллер умного дома. Управление Z-Wave сетью осуществляется с помощью web-интерфейса, использующего HTTP/JavaScript API. Используя JavaScript можно создать набор функций для автоматизации (включение/выключение света, проверка температуры, опрос датчика движения и др.), которые затем можно выполнить, послав HTTP запрос.

Продукт компании OpenRemote с одноименным названием позволяет создавать мобильные приложения для умного дома без программирования, при этом в одном приложении могут использоваться разные технологии: Z-Wave, KNX, X10, ZigBee, управление компьютером по ssh и др.

OpenRemote это сервер выполняющий любые команды и конструктор интерфейсов в котором вы создаете кнопки, переключатели, надписи и др. и этим элементам уже назначаете команды, в нашем случае это HTTP запросы на выполнение JavaScript функций на сервере Z-Wave.

Далее я по пунктам расскажу как создать пульт управления умным домом для iPhone и Android! А вот так будет выглядеть наше приложения, когда мы закончим:


Под катом много картинок.

Открывшийся недавно в режиме публичной альфы сайт Clippingmagic.com предназначен для решения всего одной задачи — удаления фона изображения, но зато делает он это весьма неплохо. В отличие от большинства подобных инструментов, он имеет удобный и простой интерфейс и при этом результат получается очень приличным. Пожалуй, лучше и аккуратнее можно сделать только в настоящем большом редакторе вроде Photoshop или Gimp, потратив при этом гораздо больше времени.



Алгоритм работы очень прост: загружаем картинку, выделяем зелёным объект, а красным — фон, затем несколькими штрихами исправляем оставшиеся огрехи. Весь процесс занимает буквально минуту-другую и не требует особой твёрдости руки. Изображение можно масштабировать, при этом размер кисти не меняется, позволяя обработать мелкие детали. Результат можно сохранить в формате PNG.

Для начала скажу что я очень большой любитель что-то попатчить и потвикать, даже если для этого нету особой необходимости. И вот недавно рассматривая статистику XCache на своем сервере я подумал что смог бы оптимизировать объем памяти который он тратит на опкеш (opcache) файлов различных фреймворков. Сделать это просто — переписать все используя только один, файлы которого были бы общими для всех сайтов, каких у меня порядка 20-ти, но в большинстве они довольно простенькие и особого труда их переписать мне бы не предоставило. И тут я начал поиск того самого фреймворка, который в идеале имел бы достаточно фич чтобы разработка была простой, и в тоже время был легким и быстрым. Вот те которые мне понравились и мои мысли о них.

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

К сожалению стандартный мануал по RBAC в YII оставляет больше вопросов чем ответов. Эту ситуацию я и намереваюсь исправить.
Я расскажу о создании “правильной” иерархии: как делать не стоит. А в завершении я приберёг инструкцию, о том как подружить LDAP авторизацию (из ActiveDirectory ) с Yii и RBAC.

Все кто заинтересовался, добро пожаловать под кат!

Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

Описание системы

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

Система является аналогом видеоглазка, подключенного к телевизору, выполняющим архивацию видео и поддерживающим просмотр видео через локальную сеть (LAN или Wi-Fi). Основными элементами системы являются: IP-камера, коммутатор с поддержкой PoE, неттоп, Wi-Fi роутер. Программное обеспечение, установленное на неттопе, обеспечивает:
— просмотр видео с IP-камеры на экране телевизора, подключенного к неттопу через HDMI;
— архивацию видео с IP-камеры на жесткий диск неттопа (1 ч видео требует порядка 1,3 ГБ);
— просмотр видео с IP-камеры на устройствах, подключенных к неттопу, как к web-серверу (работает с любым броузером);
— просмотр видео с IP-камеры на устройствах, подключенных к неттопу, как к DLNA-серверу.

Структурная схема системы:

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

Давно знаком и являюсь поклонником Яны Франк (ака Миумау в ЖЖ — www.miumau.lj.ru). Был на ее встрече позавчера, записал всю встречу на видео. Что мне понравилось: много дельных советов о борьбе с творческим кризисом, прокрастинацией в личном развитии и астенизацией. Все эти подходы применимы не только среди «художников», или тех чьи профессии считаются «творческими», но и вообще среди людей, которые хотят получать удовольствие от работы.

Вначале пару минут вступления-хождения.

От переводчика

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

Снова прошу прощения за отсутствие перевода словосочетания “computer science”.

Кратко

• Боритесь за закон Парето, следите за тем, чтобы 20% вашего труда давало вам 80% результата;
• Расставляйте приоритеты, ведь минимализм нужен для того, чтобы делать то, что нужно, а не распыляться по мелочам;
• Лучшее — враг хорошего: сначала просто сделайте, потом сделайте правильно, потом сделайте лучше;
• Убивайте в зародыше, не бойтесь начать всё сначала. Чем быстрее ошибётесь, тем быстрее научитесь;
• Повышайте свою ценность. Постоянно думайте о том, чем можно помочь команде, — и развивайтесь в этом направлении;
• Сперва основы. Мыслите последовательно, ориентируясь на лучшие практики мира Computer Science;
• Посмотрите с разных сторон. Простое получается тяжелее, чем сложное, поэтому включайте воображение;
• Синтаксис — основа взаимодействия. Мы пишем код для людей, а не для машин;
• Не запутывайте. Старайтесь проектировать слоями, по мере возможности не зависящими друг от друга;
• Вычищайте оставленное-на-всякий-случай. Минимализм борется с отвлекающим от основного.

Начало Код с душком
Техника: Составление методов

В продолжении, техника рефакторинга по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

Всем привет.

Небольшая шпаргалка для новичков, и всех остальных кто забыл, по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

Я люблю desktop-приложения. Признаваться в этом нынче, похоже, стыднее, чем в связях с иностранной разведкой, но это так. Нет, это не значит, что я не люблю интернет-технологии. Более того, некоторые я не только уважаю, а даже более-менее знаю. Но, тем не менее, я скучаю по тем временам, когда программа писалась на одном компьютере, потом компилировалась и запускалась на других, разных компьютерах. Тогда везде (почти) была одна система — Windows с одной и той же API, почти не было проблем совместимости на уровне приложений, никто не материл разработчиков браузеров — все берегли нервы на разработчиков WinAPI, которые умудрялись создавать конфликты даже внутри нее одной. Но это я, конечно, иронизирую, а если серьезно — иногда и сейчас хочется написать просто desktop-приложение, да так, чтобы работало оно на всех популярных системах. Трудно? Если подумать и покопать, то не очень.

Еще я люблю языки высокого уровня с аккуратной архитектурой и строгой типизацией. Мои фавориты — Java и C#. Оба они предоставляют разработчику множество преимуществ по сравнению с C++, оба избавляют от ряда забот. Чем приходится платить? Тем, что таскаешь за собой тяжелую колоду, которая называется Oracle JVM, .NET или mono. Все три колоды весят сотни мегабайт и лицензию имеют такую, что каждый пользователь вынужден качать эту штуку сам, не путая при этом разрядность своего компьютера, а главное — программа на Java не может быть совместима со всеми версиями JVM разом, не так ли? И вот — мы приходим к тому, что просто скинуть программку другу (или миллиону друзей) и не заботиться о том, что она у него не запустится, не выходит. Приходится делать хитрые сетапы, вбивать костыли, и это я еще не упомянул .NET — однажды я видел у друга сразу 3 установленных версии, причем все три были нужны разным приложениям…

Стоп! А давайте напишем программу на Java, но так, чтобы она не требовала установки на машину какой-либо JVM, чтобы одним касанием собиралась под Windows, Linux и OS X и чтобы при этом занимала совсем чуть-чуть; так, чтобы никто даже не понял, что она написана, скажем, не на C. Невозможно? Совсем наоборот! (И нет, я имею в виду не gcj, который лишает Java всех ее прелестей. Рефлексия будет работать и даже сторонние jar вы сможете запускать).

LibreOffice в корпоративном секторе — к старту готов

Есть на Хабре такая хорошая статья за авторством frozer, в которой рассматривается развертывание (с помощью Active Directory) и использование LibreOffice (LO) в корпоративной среде.

Единственный минус статьи — только теоретический подход. Т.е. автор описывает что можно сделать для корпоративной интеграции LO, но практическая часть отсутствует, как таковая.

Я пытался узнать секреты и получить советы на официальном русскоязычном форуме LO, и вот что получил в ответ:

Есть самый эффективный путь.
Скомпильте из иисходников под себя. Или заплатите тому, кто это сделает.

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

Инструкция — под катом.

Еще в 2009 году, Сергей Чикуёнок опубликовал статью, в которой представил новый способ написания HTML и CSS кода. Этот революционный плагин, назывался Zen Coding, он помогал многим разработчикам на протяжении многих лет и в настоящее время вышлел на новый уровень.

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

Для тех, кто предпочитает смотреть, а не читать, вот видео любимых трюков автора.