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



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

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

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

Back-typing (back-type, реже — rear-type), как явствует из названия — это способ расположения элементов ввода на задней стороне устройства. (Слово «бэктайпинг», конечно, в русском языке отсутствует, но что-то «заднепечатание» мне нравится меньше, так что в рамках данного обзора предлагаю остановиться на первом варианте.) Клавиатура Октодон — безусловный пример бэктайпинга, но не единственный и даже не первый.
Человечество предлагает нам уже изрядное количество back-typing решений, и думается, хабражителям будет интересно взглянуть на них попристальнее.

(Tina Fey, фотография Bust Magazine)

Решение сделать собственную клавиатуру пришло после анонса клавиатуры Truly Ergonomic. Всё в ней было прекрасно, кроме цены. 220$+50$ за доставку несколько превышало психологический порог стоимости доски с кнопками.

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

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

Для затравки КДПВ.



Сначала расскажу о старых клавиатурах такого типа, включая Apple, IBM и NEC, не доживших до нашего времени, потом о более-менее современных, а потом о новой волне, в том числе отечественном движении.

Благодаря начинаниям широко известного в узких кругах ibnteo (Вольки) задумался о разработке концепции эргономичной клавиатуры, удобной не только для набора текста, а и для полного управления компьютером (ага, люблю использовать в программах так называемые «горячие клавиши» — из-за них даже фотошоп использую англоязычный, да и «страшная синяя программа» FAR — это основной мой рабочий инструмент, им и файлы «гоняю», и просматриваю, и «запускаю» документы).

В стандартных компьютерных клавиатурах меня не устраивает прежде всего диагональное смещение клавиш, унаследованное от механических печатных машинок (там в этом, по утверждениям, была необходимость — хотя, были пишмашинки и без этого смещения). Затем, конечно же, хотелось, чтобы при работе не было необходимости переносить руки между функциональными «зонами» клавиатуры (основное поле, поле навигации и редактирования, цифровой блок, функциональные клавиши).
Ну и «на закуску»: неудобно расположены «шифты» (так я называю «одним словом» клавиши-модификаторы Ctrl, Shift, Alt и Win) — когда работаешь на клавиатуре двумя руками, то достаточно удобно, если привыкнуть, жать «шифты» одной рукой (но, всё равно, приходится «снимать» эту руку с основной позиции), а «горячую клавишу» — другой (а копи-паст — Shift+Ins, Ctrl+Ins и Shift+Del), но, когда в другой руке (в правой — я «правша») находится мышка, да не просто «находится», а ею активно работаешь — нажать «одной левой» горячую клавишу в сочетании с модификаторами — це́лая проблема (даже простейшие Ctrl+Z, Ctrl+X, Ctrl+C и Ctrl+V), я начинал работать с компьютерами давно и привык нажимать Ctrl больши́м пальцем, а ZXCV — указательным (ну непривычно мне Ctrl жать мизинцем! он слабый и неуклюжий!)…

Deferred объекты появились в jQuery 1.5. Они позволяют отделить логику, которая зависит от результатов выполнения действия от самого действия. Для JavaScript Deferred объекты не новы, они уже были в MochiKit и Dojo, но с изменениями логики jQuery ajax от Julian Aubourg, внедрение Deferred объектов было неминуемо. С Deferred объектами несколько callback могут быть связаны с результатом задачи и любые из них могут быть привязаны к действию даже после начала его выполнения. Выполняемая задача может быть асинхронна, но не обязательно.

Deferred объекты теперь встроены в $.ajax() таким образом вы будете получать их автоматически. Обработчики теперь могут быть связаны с результатом следующим образом:

// $.get, ajax запрос, он асинхронный по умолчанию
var req = $.get('foo.htm')
   .success(function( response ){
      // что-нибудь делаем с ответом
   })
   .error(function(){
      // делаем что-нибудь если запрос провалился
   });
 
// это выполнится перед тем как $.get() будет выполнено
doSomethingAwesome();
 
// Делаем что-то ещё перед завершением запроса
req.success(function( response ){
   // делаем  что-то ещё с ответом
   // он будет выполнен когда запрос завершится, а если запрос завершен, то будет вызван немедленно
   // если запрос уже был выполнен
});

CatBoard — это самодельная эргономичная компактная клавиатура с открытым исходным кодом, имеет множество нестандартных решений, таких как: нестандартная аппаратная раскладка со стандартными клавиатурными сочетаниями; быстрый автоповтор нажатой клавиши; Fn слой с клавишами управления курсором, цифровым блоком, функциональными клавишами; отдельные клавиши переключения раскладок; более удобное расположение Ctrl и Shift; отдельную кнопку AltTab; режим совместимости с Macintosh, позволяющий работать на нём точно так же, как и на PC; возможность прошивки без дополнительного оборудования; возможность устанавливать поверх ноутбучной клавиатуры. Благодаря открытому коду, с клавиатурой можно делать что угодно, новая прошивка заливается в считанные секунды, поэтому экспериментировать можно прямо на ходу.

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

Быстрое изменение состояния посреди анимации

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

@keyframes toggleOpacity {
  50% { opacity: 1; } /* Turn off */
  50.001% { opacity: 0.4; }

  /* Keep off state for a short period */

  52.999% { opacity: 0.4; } /* Turn back on */
  53% { opacity: 1; }
}

Вот как я использовал этот приём для имитации мигающей неоновой вывески с помощью прозрачности и свойства text-shadow:

Gulp.js это потоковый сборщик проектов на JS. Он использует Stream и действительно является очень быстрым. Для примера у меня есть проект где около тысячи stylus файлов, GruntJS нужно примерно 2.5 секунды на сборку и 2 секунды на обработку autoprefixer'ом. Gulp все это делает за 0.5 секунды выигрывая у GruntJS минимум в 4 раза.



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

В этой статье будет больше практики, мы соберем среду разработки фронтенда используя Jade и Stylus, запустим локальный сервер и подключим Livereload. Проект я выложил на Github, экспериментируйте.

Всем привет! Сегодня задача у нас следующая: необходимо создать интерфейс для загрузки картинок, который бы генерировал перед загрузкой превьюшки небольшого формата. На данный момент HTML5 вовсю шествует по планете, и, казалось бы, как это реализовать должно быть предельно ясно. Есть несколько русскоязычных статей на эту тему (вот, например). Но тут есть одно но. В рассматриваемом там подходе не уделено никакого внимания расходу памяти браузером. А расход может доходить до гигантских размеров. Разумеется, если загружать одновременно не более 5-10 картинок небольшого формата, то все остается в пределах нормы; но наш интерфейс должен позволять загружать сразу много изображений формата не меньше, чем у современных фотоаппаратов-мыльниц. И вот тогда-то свободная память начинает таять на глазах.

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

Собрав необходимую сумму на Кикстартере, американский разработчик Крис Грэнджер сдержал слово — реализовал поддержку Python и опубликовал исходный код Light Table на Github.

Доброго времени суток, уважаемые хабравчане. Многие пользуются замечательным редактором Sublime Text, который стал популярен благодаря своей простоте, гибкости/кастомизации и огромному количеству плагинов. Хочу поделиться с вами, на мой взгляд, самыми полезными шорткатами при работе с Sublime.

Переход по фрагментам

Win/Linux: CTRL+R
Mac: CMD+R
Вероятно, самое полезное сочетание клавиш для экономии вашего времени. Содержимое документа разбивается на определенные фрагменты (функции, HTML теги или CSS стили). Переход происходит при выборе соответствующего фрагмента во всплывающем окне.

Как известно, функциональный подход к программированию имеет свою специфику: в нём мы преобразовываем данные, а не меняем их. Но это накладывает свои ограничения, например при создании программ активно взаимодействующих с пользователем. В императивном языке намного проще реализовать такое поведение, ведь мы можем реагировать на какие либо события «в реальном времени», в то время как в чистых функциональных языках нам придётся откладывать общение с системой до самого конца. Однако относительно недавно стала развиваться новая парадигма программирования, решающая эту проблему. И имя ей — Functional Reactive Programming (FRP). В этой статье я попытаюсь показать основы FRP на примере написания змейки на Haskell с использованием библиотеки reactive-banana.

Предыстория

30 ноября 2013 года появились первые сообщения от пользователей что у них:

• Возникла ошибка при запуске ....dll
• Запуск программы невозможен так как отсутствует ....dll
• Не найдена библиотека ....dll
• Слет активации (как следствие пропажи системных файлов)

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

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

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

Хочу сразу оговориться: REST для меня — это, в первую очередь, идеология, к которой я отношусь трепетно и нежно. И, если кто-то не готов принять ее такой, какая она есть — не стоит читать дальше эту статью. У программиста всегда есть куча полезных дел, которыми можно заняться, пока приходит понимание необходимости писать узнаваемые интерфейсы и прятать за их простотой логику приложений любой сложности…

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

Теперь давайте по порядку.

...Skype — это дьявольски хитрая программа, написанная бесспорно талантливыми людьми..._{Крис Касперски}

Доброго времени суток!

Skype сейчас я встречаю чаще на компьютерах чем другие IM клиенты, мне он практически заменил icq, вся рабочая переписка ведется в skype, но речь пойдет не о том, что лучше или популярней. Часто бывает так, что участвуешь сразу в нескольких чатах где количество участников превышает 10, что собственно и приводит к тому, что на рабочем столе и в трее постоянно обновляется количество новых сообщений, а также уведомления в виде всплывающих сообщений, а теперь представьте что у вас 3 окна чата с друзьями, 1 с вашим боссом, другой с девушкой — все это в сумме начинает запутывать, отвлекать и порой раздражать. Хотелось бы расставить приоритеты…

Раньше я чаще всего настраивал «политику» уведомлений только через глобальные настройки программы
Случилось так, что я узнал, что в каждом окне чата skype возможно использование команд, например /alertsoff отключит уведомления для конкретного окна чата, соответственно /alertson включит их обратно.
Поискав немного я наткнулся на некое how-to, оказывается у skype чата довольно много текстовых команд, подобие IRC команд. Далее я постарался попробовать все возможные из них на двух имеющихся у меня платформах, как оказалось не все и не везде работает… Прошу под кат.

В каждой избушке — свои игрушки

До некоторого момента front-end разработчик при написании javascript кода, рассчитанного на взаимодействие с пользователем, ориентировался лишь на «мышиные» события. Затем появились различные устройства, которые использовали другие формы взаимодействия пользователя с приложением — сенсоры или перо. Типы событий для каждого устройства были предложены индивидуальные. Так, кроме mousedown, mousemove итд., появились touchstart, touchmove и другие события.

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

• События мыши возникают только после сенсорных;
• Наведение мышью (mouseover) и другие аналогичные события не сработают без прикосновения к устройству. Обработчики таких событий должны быть запущены по умолчанию или их нужно заменить на событие 'click' по элементу;
• События по щелчку не будут запущены при изменении DOM дерева документа;
• События по щелчку срабатывают не сразу, а, приблизительно, через 300 мс;
• Touch и mouse события, в некоторых случаях, конфликтуют между собой.

В результате, front-end разработчику при написании приложения приходится обрабатывать несколько видов событий, события мыши на десктопных ПК и touch события для сенсорных устройств. Код становится громоздким, процесс разработки — трудоемким…

На тему шаблонизаторов статей написано великое множество, в том числе и здесь, на хабре.
Раньше мне казалось, что сделать что-нибудь своё — «на коленке» — будет очень сложно.
Но, случилось так, что прислали мне тестовое задание.
Напиши, мол, JavaScript шаблонизатор, вот по такому сценарию, тогда придёшь на собеседование.
Требование, конечно, было чрезмерным, и поначалу я решил просто игнорить.
Но из спортивного интереса решил попробовать.
Оказалось, что не всё так сложно.

Собственно, если интересно, то под катом некоторые заметки и выводы по процессу создания.

Для тех, кому только глянуть: the result, the cat.