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

Все началось с того, что клиент, как бы между делом, написал: "Смените цвет иконки на Королевский синий." (на английском — Royal Blue) Сказать честно, для меня такая постановка задачи показалась необычной. Вот есть темно-синий, светло-синий и просто синий, но никакого королевского я не знаю. Пришлось искать.

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



Почему бы не использовать активнее эти названия в профессиональном лексиконе дизайнера? Не бездушные цифро-буквы вроде #C41E3A или R:196 G:30 B: 58, а красивые слова — цвет «Кардинал». Тогда речь дизайнера будет звучать как стихи. Например: "Я считаю, что сочетание текста цвета Светлая Вишня и фона цвета Шартрез делают композицию очень необычной. Если добавить нефритовых пятен в качестве акцентов, то вообще будет опупенно."

У авиакомпаний было 90 лет, чтобы нарисовать посадочный талон, и они все равно облажались. Я предлагаю сделать так:

Несколько дней назад я имел возможность основательно попрактиковаться в разработке приложений для Google Glass. Полученный опыт растеряется со временем, так как пока разрабатывать что-то ещё под “очки” не планирую. Чтобы поделиться пока ещё свежими впечатлениями решил написать этот топик.
Думаю, всем кто интересуется Google Glass известно, что представляет собой программная “начинка” этого гаджета. Да, это Android 4 с адаптированным launcher-ом. Да, в “очках” вполне можно запускать обычные android-приложения, установив их туда через adb. Известно вам наверняка и про Mirror API, который до недавнего времени считался единственным способом официально предоставить свой сервис пользователю Google Glass. Ниже я немного расскажу о использовании этого инструмента. Но главное, о чём хотелось бы рассказать — как писать под Google Glass полноценные android-приложения, используя пока ещё не официальный Glass Development Kit.

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

Все знают офисных монстров PowerPoint и Keynote, но почему-то мало кто с радостью в них работает. И действительно, что делать, если ты совсем не бухгалтер, а разработчик или просто гик и гораздо комфортнее чувствуешь себя в коде, чем в офисных пакетах? У меня для тебя хорошие новости: презентации уже очень давно можно делать прямо в браузере, а писать с помощью таких простых и знакомых вещей, как HTML, CSS или даже Маркдаун.

К каждому из нас приходит момент, когда нужно донести свои мысли до других. Не просто рассказать анекдотец коллеге, не пробубнить стишок про бурю-мглою, а сообщить что-то принципиально важное, объяснить сложную идею, поделиться опытом. И если самым талантливым из нас достаточно выйти на сцену и просто быть собой, как это делают участники TED, то большинству понадобится опереться на слайды. Свой первый раз у доски с маркерами я забыл напрочь, помню только, что переврал тогда ключевую идею доклада про блочную модель CSS.

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

Вам кажется, что кто-то подключился к вашему Wi-Fi, перехватывает пакеты и следит за вами? А может, в свете последних новостей, вам захотелось уйти в подполье? Тогда встречайте проект Bunny.py — средство для незаметной передачи данных при беспроводных коммуникациях.

Американец Паркер Томпсон разработал приложение, с помощью которого можно эффективно скрывать трафик в пакетах 802.11. Приложение позволяет поднять собственную беспроводную сеть между устройствами, которая будет невидима для постороннего наблюдателя (darknet), — а все потому, что ее трафик будет замаскирован в посторонних Wi-Fi-пакетах.

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

Мы видим этот тренд и видим примеры реализации пользовательских интерфейсов на HTML5, не уступающих по качеству нативным приложениям, и верим, что за HTML5 стоит будущее кросс-платформенных мобильных приложений.



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

Мы в DevExpress организовали небольшую команду, которая на протяжении нескольких месяцев анализировала и пробовала различные существующие средства и подходы. Результат полученного опыта — PhoneJS — наше комплексное решение для создания кросс-платформенных мобильных приложений на HTML5.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

Новички в Ангуляре часто путаются из-за того, что быстрые функции $http-сервиса (напр., $http.post()) не взаимозаменяемы с эквивалентными функциями Джиквери (напр., jQuery.post()), не смотря на то, что соответствующие руководства описывают их использование схожим образом. То есть, если код в Джиквери до этого имел вид:

В современной разработке ваш код сильно отличается от кода на «боевом» сервере (production) после компиляции, минификации, объединения и разных оптимизаций. Тут-то и вступают в игру карты кода (source maps), показывая точное соответствие элементов готового рабочего кода проекта и вашего кода разработки. В этом вводном уроке мы возьмём простой проект и запустим его с помощью различных компиляторов JavaScript с целью посмотреть работу карт кода в браузере.

Как часто Вы используете конструкции вида «5 минут назад», «Полчаса назад» на вашем сайте? А что если пользователь открыл вкладку и забыл про нее на пару часов? «5 минут назад» явно теряет свою актуальность.
Именно для того чтобы исправить это досадное недоразумение служит uptodate.js

Когда у вас возникнет вопрос, как выбрать диагональ экрана, или в каком разрешении скачать фильм, предлагаю воспользоваться таблицей Головина для выбора диагонали экрана (pdf, 85 Кб). Название я придумал сам, надеюсь, Головин был бы не против.



С появлением первых телевизоров с разрешением 4к (3840 × 2160), я хотел обновить график для определения оптимального расстояния до экрана. Но, поскольку там указаны рекомендуемые расстояния, это бы снова вылилось в субъективные обсуждение возможностей зрения каждого. Новая таблица, теоретически, должна помочь каждому сделать выбор, в не зависимости от остроты зрения.

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

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

И так, встречайте — Dater, и его основные возможности:

• Биндинг форматов
• Локализация текстов и форматов
• Расширение списка опций форматирования
• Автоопределение часового пояса
• Конвертация времени с учётом часового пояса
• Автоматическая конвертация времени в $_GET, $_POST, $_REQUEST с учётом часового пояса
• Автоматическая конвертация часового пояса в шаблоне отправляемых данных

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

Картинка для привлечения внимания

Когда я поступал в Массачусетский технологический институт, я с удивлением обнаружил, что в рунете нет не то что мало-мальски съедобной «истории успеха», связанной с поступлением в MIT, а вообще хоть какого-то руководства по поступлению в топовые американские университеты своими силами. Особенно на бакалавриат. Я подумал: «Что ж, видимо, придется написать мне». Я постараюсь донести информацию в наиболее понятном виде.

Сегодня группа разработчиков Phalcon выпустила первую бета-версию фреймворка Phalcon 1.0.0. Для тех, кто не в курсе: Phalcon — это PHP-фреймворк, написанный на Си и работающий как расширение для PHP, прочитать про него на Хабре можно в статьях Phalcon — скомпилированный PHP MVC Framework и Phalcon: Давайте учиться на примере.
Цель выпуска этой версии — получение обратной связи от сообщества и обнаружение максимума ошибок.



Краткий анонс важных нововведений этой версии:

1. Многоуровневое кеширование
2. Улучшения в шаблонизаторе Volt
3. Горизонтальный и вертикальный шардинг
4. Запись состояния (Record Snapshots)
5. Динамическое обновление
6. Валидация

UPD3: наткнулся на статью, написанную на схожую тематику. И хотя появление двух таких статей с разницей в сутки — не более чем случайность, но моя вышла позже, а посему я чувствую необходимость это как-то прокомментировать. Во-первых, мне стали более понятны слова AbnormalHead. Если бы я прочитал ту статью раньше, моя не увидела бы свет в том виде, в котором она появилась. Во-вторых, я хотел бы более явно сформулировать цель моей статьи. Когда я собирал свою машину, я столкнулся с тем, что найти материнскую плату с двумя встроенными сетевыми адаптерами под Mini-ITX — это достаточно большая проблема в принципе (с тех пор ситуация в этом направлении улучшилась). Найти то же, но с более чем четырьмя портами SATA — проблема и сейчас, лично я другой кроме описанной в моей статье не знаю. Да, можно поставить дополнительный контроллер, но тогда придется отказаться от чего-то другого. То же и с mini-ITX корпусами: обычных полно, но они не подходят для NAS. Есть корпуса под NAS, но нестандартный блок питания с мелким и высокооборотным вентилятором будет раздражать если не вас, то ваших близких. Найти максимально гибкое решение, которое позволит не идти на компромиссы и собрать хоть NAS, хоть сервер виртуализации, хоть роутер — не так просто. В какой-то момент я уже думал, что невозможно. Однако же оно нашлось и именно им я хочу поделиться в этой статье. Да, она не про умный дом, но имея COM-порты, GPIO и Watchdog на плате его можно построить, а через LVDS можно прикрутить ЖК-экран от старого ноутбука, или вовсе управлять машиной удаленно через vPro/iAMT. Да, она не про NAS, потому что в ней нет ни слова о производительности и софте для этих целей, но из этой машины получится прекрасный NAS (и если взять соответствующий задаче процессор и объем памяти, то цена будет сильно ниже той, что вышла у меня). Да, она и не про домашнюю виртуализацию, потому что здесь не описан мой опыт установки SCVMM (тем более что он еще не закончен). Статья про платформу, на которой все вышеперечисленное можно без особых проблем организовать хоть вместе, хоть поотдельности. И при этом у вас будет не монстр, ревущий на всю квартиру и занимающий полкомнаты, а маленький, тихий, холодный корпус, который можно подключить к любому находящемуся поблизости монитору/телевизору, или не подключать вовсе. Надеюсь, этот опыт будет кому-то полезен.

Свой первый домашний сервер я собрал в 2008 году: Celeron E1400 на mATX платформе ASUS и всё это в прекрасном корпусе Antec NSK 1380. Корпус действительно хорош за исключением двух моментов: 1. Нестандартный формат блока питания (и как следствие возможность поставить только низкопрофильное охлаждение на процессор) 2. Малое число посадочных мест под накопители и плохое их охлаждение (поэтому я никогда не ставил туда больше одного диска — и так было тесно и жарко).

С ролью маршрутизатора эта машина справлялась прекрасно. Но организация на ней файлопомойки уже создавала неудобства: место вечно кончается -> приходится менять диск на новый большего размера (ну не чистить же его в самом деле!) -> для этого надо перенести на новый диск систему -> уж если переносишь, то не обновить ли ее заодно, а то пакеты с новыми часовыми поясами под текущую приходится искать чуть ли не собаками (пламенный привет Федоре) -> … И так каждый раз.

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

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

Требования:

• бесшумность
• компактность
• возможность удобной установки/замены дисков и достаточное количество посадочных мест (от 4)
• универсальность (больше разъемов/интерфейсов, всяких и разных, мало ли что захочется прикрутить)

Форм-фактор Mini-ITX не был обязательным критерием, но логично вытекал из второго пункта. Поэтому я решил для себя, что попытаюсь выжать из него максимум и только в крайнем случае начну смотреть в сторону mATX.

После публикации прошлой статьи, я полностью забил на попытку выполнить алгоритм при помощи HSV или Lab координат. Забил на использовании библиотек цветов и вообще на сам скрипт забил.

Но что-то стало скучно и опять зачесались руки поработать с изображениями и одновременно захотелось исправить уже имеющийся алгоритм.
Скрипт: link

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

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

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