Вступление

Я думаю все слышали про Mac OS X как операционную систему для дизайнеров и домохозяек. Но хочется рассказать про средства разработки для OS X, а то хорошие программы пишут, а на чем — никто не знает.

Сразу скажу, что не буду рассказывать про кроссплатформенные фреймворки и тулкиты(такие как Qt) или про создание консольных приложений, я расскажу про то, что в плане создания приложений отличает Mac OS X от других операционных систем, а именно — фреймворк Cocoa. Оговорюсь сразу, что буду стараться избегать сравнений с другими фреймворками, я хочу просто рассказать про Cocoa.

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

Компания Apple приглашает новичков начать разработку своих приложений под iOS, и в помощь опубликовала руководство "Start Developing iOS Apps Today", где указаны все необходимые действия на каждом этапе, даются советы по выбору языка программирования, дизайну интерфейса приложения и максимизации прибыли в App Store.



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

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

• Убедитесь, что срок действительно жесткий
• Не берите на себя проекты с нереальными сроками
• Планируйте методом «набегающей волны»
• Периодически пересматривайте оценку проекта
• Оценивайте проект эмпирически
• Привлекайте к первоначальной оценке команду

Не один раз в комментариях замечал что народ негодует по поводу того, что веб-разработчики стали злоупотреблять использованием Bootstrap от Twitter. Признаюсь, я и сам успел закончить несколько небольших веб-приложений с использованием этого набора скриптов и стилей. Я не против использования Bootstrap от Twitter, я против злоупотребления этим когда есть столько хороших альтернатив. Я почти каждый день натыкаюсь на интерфейсы, построенные на Twitter Bootstrap, и это начинает напрягать. Последней каплей для поиска альтернативы стало изменение интерфейса биллинг панели моего хостера на шаблон Bootstrap. В этой записи я хотел бы немного рассказать про одну из альтернатив — HTML KickStart.

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-ноябрь 2011.

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

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

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

Введение

К своему стыду, я совсем недавно познакомился с элементом details, который по сути является виджетом для представления информации о чём-либо. По информации, которая есть у меня, его поддержка достаточна скудна, так как поддерживается он на данный момент лишь в Google Chrome, начиная с 12.0, а также в Android Browser, начиная с версии 4.0. Что же, давайте посмотрим, что это за зверь такой.

На всякий случай — это перевод (многие не замечают этого в интерефейсе ХабраХабра).
«Fat-Free» можно перевести с английского как «Обезжиренный» — фреймворк и в самом деле поражает своим размером (55 КБ) и скоростью работы.

Я наконец-то нашёл лёгкий и быстрый фреймворк. Он умещается в файл размером всего 55Кб и имеет множество возможностей, о которых вы можете узнать на его официальном сайте, поэтому не буду повторяться. Вместо этого я решил сделать небольшой учебник, из которого вы узнаете как сделать свой блог на этом фреймворке.
Вам понадобится PHP 5.3 на сервере. Я использовал Ubuntu 11.04 для написания этого учебника, на которую легко устанавливается эта версия. Если вы работаете на RHEL или Centos то я предлагаю заглянуть вам на IUS Community Project для получения последней версии PHP.

Чем больше я работаю над своим первым проектом на работе, тем больше мне хочется в нем поменять и тем больше я жалею о том, что перед началом работы я не прочитал до конца «The Definitive Guide to Symfony» и не изучил плагины для Symfony. Многие из них мне бы помогли намного сократить время разработки и, что самое главное, не думать о том, как красиво реализовать те или иные вещи… И еще одно — если у вас уже есть кусок системы (как это было у меня), который вы собираетесь переписывать с использованием вашего фреймворка (или просто переписывать, потому что код вам не нравиться) — то мой вам совет — потратьте время на то, чтобы спроектировать этот кусок на план вашей новой системы, не бросайтесь сразу всё переписывать (каюсь, я поступил именно так), так как после анализа (который, возможно, займет у вас не один день, и даже не одну неделю), возможно, от предыдущей архитектуры системы не останется и следа.
Вообще, я люблю проектировать, продумывать, анализировать те или иные решения, которые хочу внедрить в систему (хотя, признаюсь, опыта у меня в этом маловато), но как обьяснить заказчику, что ты провел день в раздумьях… Эх…
Ну ладно, это я отвлекся. Сегодня хочется рассказать о том, с чего стоит начать при разработке системы с помощью Symfony и каких правил следует придерживаться.

Всегда мне не нравилось, как выводятся изображения на моих сайтах. Хотелось какой-то упорядоченности, зависимости. Поэтому, я полез искать скрипты и решения в гугле. После безуспешных поисков, решено было делать что-то самому.
Но что? Я стал смотреть, как сделан вывод картинок у популярных сайтов. Всё мне не нравилось, пока я не додумался посмотреть вывод в google images и google+. Меня поразило то, что я никогда этого не замечал картинки выравниваются по ширине и высоте не обрезаясь. Такой принцип я и захотел реализовать. Получается мозаика. И всё будто на своём месте.
Не долго думая, я сел писать код, который сможет вывести картинки так же.

Часть 1
Часть 3
Продолжаем строить гусеничного робота.
В первой части мы с вами подобрали и, надеюсь, заказали все необходимые детали. Кстати, недавно проверял, все детали Tamiya (гусеницы, площадки, мотор-редукторная коробка) были в наличии в Terraelectronica. Подороже, конечно, чем из Китая, но зато рядом.
Те, кто уже получил детали, наверняка уже собрали шасси.
Теперь займемся бортовой электроникой, видеоподсистемой и питанием.

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

Я всегда мечтал создать робота, которым можно управлять с помощью компьютера и смотреть за его перемещениями от первого лица.
Весь процесс я условно разделил на три части:
1. Сборка робота
2. Программирование боротового микроконтроллера
3. Программирование управления с ПК

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-сентябрь 2011. В связи с повышенной конференционной активностью этой осенью вышла пауза с публикациями, но дальше такого наплыва мероприятий не будет.

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

Так например не далее как вчерашним вечером Павел Дуров и Юрий Мильнер анонсировали свой проект по безвозмездному финансированию софтверных стартапов.

Обещают выборочно давать ~$25.000 и не просить ничего взамен.

Ката не будет. Вот ссылка на сайт меценатов.
Вот страница «на сайте Павла».
И вот интервью, которое взял у Павла Дурова @nickolaykononov.

Вроде всё просто и круто.

Если кто помнит, в первой части своей статьи о гарантиях я упоминал о «подразумеваемых гарантиях» (Implied Warranties), которые автоматически являются частью контрактов на разработку ПО, т.к. они закреплены законодательно. В британском законодательстве эти гарантии закреплены в The Sale of Goods Act 1979 и The Supply of Goods and Services Act 1982. Напомню, что к «Implied Warranties» относятся: 1) Warranty of Title, 2) Infringement Warranty, 3) Warranty of Merchantability, 4) Warranty of fitness for а specific Purpose.Мы говорили о том, что если прямо не исключить действие этих гарантий, то они будут распространяться на правоотношения в рамках этого контракта. Теперь я предлагаю рассмотреть варианты исключения действия этих подразумеваемых гарантий.

В первую очередь стоит отметить, что если мы говорим о праве Великобритании, то все исключения «warranties» должны соответствовать требованиям, которые предъявляет UTCA (Unfair Contract Terms Act 1977). В соответствии с UTCA, некоторые «implied warranties» вообще не могут быть исключены (например, «Warranty of Title»), а некоторые, могут быть исключены только целесообразно — «only if reasonable» (например, «Warranty of fitness for а specific Purpose»). Если суд придет к выводу о том, что условие об исключении гарантии идет в разрез с требованиями этого нормативного акта, то это условие будет считаться недействительным. Во избежание рисков, связанных с нарушением UTCA, и в целях обеспечения исключения максимального числа гарантийных обязательств, разработчик может воспользоваться следующей конструкцией: «Other warranties are excluded to the maximum extent permitted by law».

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



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

Если кто-то захочет попробовать, я сделал простой пример системы, который показывает общее развитие сценария.

Навеяно статьей об обработке критических ошибок в PHP. Обратил внимание, что несмотря на то, что коды ошибок в PHP специально заточены под битовые операции, тем не менее, что в примерах статьи, что в комментариях, для проверки кодов ошибок используются обычные операторы сравнения.

Например, встречались такие варианты:

if ($error['type'] == E_ERROR || $error['type'] == E_PARSE || $error['type'] == E_COMPILE_ERROR){…}

или

if(in_array($error['type'], array(E_ERROR, E_PARSE,  E_COMPILE_ERROR)) {…}

В связи с этим решил написать небольшую статью о битовых операциях с примерами их использования.

Интернет наполнен огромным количеством документации для веб-разработчиков. Но, к сожалению, использование большей части документации довольно неудобное. Для примера, возьмем Mozilla Developer Network (MDN). Сайт Mozilla Developer Network предлагает большой объем документации по CSS, JavaScript, HTML, SVG и т.д., но навигация по нему утомительна — нет никакого глобального меню и поиск не столь удобный.

Это привело разработчика Рафаэль Гарсия создать instaCSS — быстрый способ просматривать документацию CSS от MDN. Благодаря хорошей функции поиска и чистому, простому дизайну с хорошим глобальным меню instaCSS стал хитом по мнению читателей Hacker News. В связи с большим спросом, Гарсия перевел проект на более широкий домен DocHub.io и расширил поиск по CSS, HTML, JavaScript и DOM.