Говоря о шаблонных сайтах, мы нередко слышим, что такие проекты не живут дольше нескольких месяцев. Потенциальные клиенты, услышав слово «шаблонный», не хотят продолжать разговор и делают обиженные лица. Студии, которые делают «шаблонные» решения – часто лишены должного уважения в профессиональном сообществе. И, наконец, сайты, которые дешевле 20 000 руб часто называют, простите, «говносайтами». Вы тоже так думаете? Давайте разберемся насколько это действительно так и восстановим мировой баланс (если он существует).

Стипендия фонда Джона и Кэтрин Мак-Aртур, известная так же под названием "грант для гениев" составляет 500 000 долларов, которые выплачиваются частями в течение пяти лет, и присуждается ежегодно нескольким десяткам людей, имеющих, по мнению экспертов фонда, потенциал для выдающихся творческих достижений в своей области. Среди лауреатов этой премии — Тим Бернерс-Ли, Иосиф Бродский, Ричард Мэттью Столлман, Макс Роуч и многие другие люди самых разных профессий. Особенность премии — лауреаты часто узнают о том, что им присудили премию, постфактум. Для того, чтобы получить этот грант, не нужно подавать заявку или участвовать в конкурсе. Деньги достаются лауреатам без каких-либо специальных усилий и без каких-либо условий.

По образу и подобию «гранта для гениев» Чед Витакер создал краудфандинговый сервис Gittip. Любой обладатель аккаунта на Гитхабе может стать участником своеобразного «фонда взаимопомощи» — платить авторам понравившихся проектов или получать деньги самому. Как это работает? Достаточно войти на gittip.com через Гитхаб и привязать к аккаунту платёжную карту. После этого вы можете ввести в поле поиска гитхаб-имя того, кому вы хотите помочь материально, и если этот человек уже присоединился к фонду — он будет получать выбранную вами сумму каждую неделю. Если же нет, он будет занесён в список потенциальных получателей. Естественно, никаких денег без ведома самих получателей никто не собирает — всё по-честному. Деньги перечисляются только на активированные аккаунты. При желании можно вообще исключить своё имя из всех списков. В будущем рассматривается возможность рассылать потенциальным получателям уведомления, подобно тому, как социальные сети предлагают разослать приглашения друзьям, которые ещё не зарегистрировались.

Grunt — это инструмент для сборки javascript проектов из командной строки с использованием задач. Релиз вышел совсем недавно, автор Ben «Cowboy» Alman, проект есть на github. В этой статье я рассмотрю основы Grunt, его установку и использование.

^{Тут наверняка есть косяки, просто мы ещё не открыли коробку}

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

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

Представьте задачу:

• Вы решили стартовать IT-проект, который требует большой вычислительной мощности.
• «Взлетит» он или нет, станет понятно через 3 месяца.
• Космически дорогое железо (несколько серверов по цене квартиры в Москве каждый) покупать не хочется, но при этом надо сразу стартовать так, чтобы потом не было сложностей с масштабированием до серьёзной highload-системы, то есть хочется эластичного «облака».
• В перспективе — необходимость быстро обрабатывать много данных и массу операций чтения-записи. То есть, потребуются тяжелые сервера-«молотилки», которые не могут горизонтально масштабироваться – такое в «облако» не запихнёшь.
• При этом надо создать единое сетевое пространство, как если бы «молотилки» вашего ЦОДа и сервера «облака» находились в соседних стойках, и настроить всё так, чтобы на уровне приложений не приходилось думать про физическое воплощение железа;
• Обеспечить адекватную техподдержку, которая способна закрыть все вопросы по проекту (сеть, сервера, прикладные системы) — и всё это без поиска новых администраторов себе в штат.
• До кучи — запуститься очень быстро;
• И всё это —в Москве, чтобы обеспечить минимальные лаги.

В начале этого года к нам пришел заказчик именно с такими задачами.

Преамбула

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

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

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

О неточностях, опечатках, ошибках пишите в личку — буду оперативно исправлять.

Вступление

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

Начнем с взаимного расположения точки относительно прямой, луча и отрезка.

Делаю тут проект и возникла вот какая проблема. Получаю данные с АЦП (дельта-сигма) микросхемы в которую встроен контроллер и фильтр, но этот фильтр имеет довольно убогую АЧХ, в итоге идёт завал по ВЧ от 60Гц и далее. Выглядит это примерно так:


Т.е. такая неравномерность АЧХ нас явно не устраивает (не проходит по техническим требованиям), правда есть возможность повысить частоту дискретизации с 250Гц до 500Гц, чтобы выровнять АЧХ, однако тогда увеличивается объём данных который ещё нужно будет усреднять, что скажется на производительности (проект на STM32F103VE) системы в целом и на общем потреблении энергии (батарейное питание). Но есть и другой путь.

Первая статья про мой небольшой хостинг вышла в 2010 году.
С тех времен прошло почти 2 года, добавлялись и менялись сервера, менялась структура, менялись технологии. В данный момент готовлюсь к переезду в Новосибирск и решил раскрыть карты и хитрости своего маленького хостинга.
Статья будет интересна специалистам наших обширных территорий, где до сих пор отсутствует нормальный «внешний» Интернет, тем, кто хочет построить хостинг с распределением нагрузки на сравнительно недорогом оборудовании.

Когда я работал над сервисом заметок jotsky.com, еще до работы в Островке, надо было сделать ввод телефонного номера из двух инпутов. Примерно такой:



Я сделал навигацию с помощью стрелочек. Сделал, чтобы по мере заполнения фокус переключался к следующем инпуту. А вот сделать правильную вставку из буфера обмена у меня никак не получалось.

Что будет, если генератор случайных фигур соединить с детектором лиц? Способен ли эволюционный алгоритм путём случайных мутаций сгенерировать человеческое лицо? Разработчик программы Pareidoloop отвечает на этот вопрос утвердительно (генератор протестирован только в Chrome 21).


^{(с) spiritedflow}

Сегодня разнообразные открытые СУБД встают лицом к лицу против массивных, неуклюжих и дорогостоящих «корпоративных» систем, таких как SQL Server и Oracle. Часто открытые СУБД прекрасно работают лучше закрытых систем, не уступая даже в функциональных возможностях.

Из всех открытых систем управления базами данных самой умной, производительной и функциональной системой является Postgres, которая заслуженно привлекает всё больше и больше внимания.

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

К системе управления сборкой проекта выдвигаются следующие требования:

1. Компиляция из coffescript в javascript. Если в файле coffeescript содержится ошибка, то в консоли должны отобразиться название файла и сообщение об ошибке.
2. Сборка проекта в один javascript файл должна производится с учетом зависимостей.
3. Возможность собрать все приложение целиком в один файл в нескольких видах (с комментариями, минимизированный). При этом само приложение может состоять из нескольких модулей.
4. Сборка тестовых файлов и их выполнение в консоли (да, разрабатываем для веба, при этом не притрагиваемся к мышке и вообще не вылазим из любимого vim'a).
5. Конечно же все это должно быть удобно в использовании.

В данной статье я не буду затрагивать вопрос тестирования, а рассмотрю вариант системы управления сборкой javascript/coffescript проекта (и саму структуру проекта) с использованием rake и Rake::Pipeline (git).

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



Понять последних можно, ведь большинство статей и agile-евангелистов говорят, примерно следующее: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»

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

---

Представьте, что вы Нео, и вы — первый человек на Земле, которому пришла в голову идея написать роман. То есть что-то вроде рассказа, но подлиннее. И вы очень гордитесь своим изобретением.

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

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

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

От переводчика: Это перевод заметки товарища по имени Steve Souders, который очень плотно занимается вопросами производительности веб-сайтов и даже написал пару неплохих книг на эту тему.

Вчера я проводил семинар в Google Ventures для некоторых из инвестируемых ими компаний. Я не знал насколько подготовленной в вопросах производительности будет аудитория, так что я сделал обзор вопросов, связанных с производительностью, начиная с первых моих выступлений в 2007 году. Уже несколько лет я не рассказывал о методах улучшения производительности, описаных в моем блоге "High Performance Web Sites". Я прошелся по таким вещам, как Меньше HTTP-запросов, Добавление заголовка Expires и Gzip.

Но мне надо было вернуться еще дальше. Думая о тех временах, когда еще не существовало конференции Velocity и самого понятия WPO, я решил, что должен пояснить почему я занялся именно клиентской оптимизацией. Я нашел слайды, поясняющие «Золотое правило производительности»: 80-90% времени ожидания пользователем занимает работа браузера.

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

13 июля, одновременно с выходом новой версии Firefox, было объявлено о новой версии Firebug (установить) — наиболее продвинутого и признанного отладчика фронтенда. Вместе с тимлидом разработки Jan 'Honza' Odvarko (его блог и прочие статьи о Firebug, где немало интересного) рассмотрим его новые возможности. Это тем более интересно, потому что сам браузер потихоньку набирает силы в отладке, и куда деваться — конкурент Хром подгоняет и обгоняет, и теперь даже вполне достаточно штатных средств отладки — показ и хождение по DOM, например, в 10-й версии уже такое, что для исследования багов аддон Firebug ставить не обязательно, а в 15-й версии обещается отладчик JS, быстрый и не влияющий на производительность страницы, со средствами удалённой отладки (важно для мобильных устройств). По тому же пути идёт Опера. (--прим. перев.).

Позвольте рассказать о новых возможностях вышедшего релиза Firebug 1.10.

В первую очередь, уточним, к каким версиям Firefox относятся последние версии Firebug:
Firefox 5.0 – 13.0 работает с Firebug 1.9,
Firefox 13.0 – 16.0 работает с Firebug 1.10.

С тех пор, как вышли книги «Adaptive Web Design» Аарона Густафсона и «Responsive Web Design» Итана Маркотта (русское издание называется «Отзывчивый веб-дизайн»), в сообществе веб-дизайнеров и разработчиков ведутся споры о том, чем отличаются эти 2 подхода. Одни считают, что эти 2 понятия являются синонимами, а другие, что это совершенно разные понятия. Но, как известно, истина всегда где-то посередине, поэтому предлагаю вашему вниманию перевод статьи финского веб-дизайнера и разработчика Вильями Салминена (Viljami Salminen) «Adaptive vs. Responsive, what’s the difference?»:

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

Сейчас существует сразу несколько проектов, которые можно назвать библиотеками открытого программного обеспечения и исходников этого ПО. Среди прочих таких проектов — GitHub и Sourceforge. Проекты всем хороши, кроме того, что найти нужное ПО и исходники порой достаточно сложно. Для упрощения жизни программистам и им сочувствующим корпорация Google запустила в 2006 году сервис Google Code Search. По замыслу, сервис позволял искать нужные данные на любых сервисах, подобных GitHub и Sourceforge. Google Code Search нашел свою нишу, и его возможностями пользовалось достаточно много специалистов. Но недавно корпорация объявила о прекращении поддержки этого сервиса.