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

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

Средств для визуального проектирования становится все больше. Одни пользуются Adobe InDesign, другим нравится Visio, третьи довольствуются OpenOffice Draw. Но все больше поклонников появляется у довольно тяжелой и функциональной программы Axure RP Pro.

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

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

Любовь к HTML5 продолжает вдохновлять Поля Айриша. Во-первых, он подарил нам Modernizr, а сейчас он объединился с Divya Manian для создания шаблона HTML5, который использует передовые техники, чтобы Вы могли начать использовать его в своей практике.

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

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

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

Задачи решаемые системой:
— удобная загрузка файлов;
— возможность асинхронной обработки картинок;
— легкая работа с превью;
— отделение конфигурирования от выполнения.

Поехали

Приветствую!

В своей дипломной работе я проводил обзор и сравнительный анализ алгоритмов кластеризации данных. Подумал, что уже собранный и проработанный материал может оказаться кому-то интересен и полезен.
О том, что такое кластеризация, рассказал sashaeve в статье «Кластеризация: алгоритмы k-means и c-means». Я частично повторю слова Александра, частично дополню. Также в конце этой статьи интересующиеся могут почитать материалы по ссылкам в списке литературы.

Так же я постарался привести сухой «дипломный» стиль изложения к более публицистическому.

1. Верстка, аутсорсинг и технические задания

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

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

Мы проводили весной исследование о влиянии социальных медиа на потребительское поведение в России, и решили сделать ролик о влиянии SM на современные коммуникации как в РФ, так и во всем мире. Ролик больше образовательный, но интересующиеся SM-рынком найдут там несколько любопытных цифр.

Что такое CouchDB для вас? Вероятно любой, кто хоть немного интересуется популярной нынче темой NoSQL, прекрасно знает общие детали: это такая симпатичная игрушка с map/reduce-запросами, которые пишутся на JavaScript, с которой можно работать, гоняя JSON по HTTP-протоколу, а также не исключено, что слышали, что она fault-tolerant, тобишь не ломается вообще. Дальше этого обычно дело не идёт, в результате CouchDB отправляется в delicious в общую кучу со всякими MongoDB, Cassandra, Hadoop и т.п.

Примерно такого мнения придерживался и я вплоть до недавнего времени, пока не возникла острая необходимость переосмыслить архитектуру текущего проекта (упёршегося лбом в свою реляционную БД) и пересесть на документную базу данных, которая бы умела map/reduce. После того, как более пристально взгялнул на CouchDB, я понял, что он уникален в своём классе, его не следует ставить в один ряд с упомянутыми продуктами. Идеи, которые заложены в CouchDB настолько концептуальны, что способны в корне перевернуть представление о разработке веб-приложений.

О том, что же меня так впечатлило, постараюсь рассказать под катом.

Если вы полагаете, что масштабируемость Вашего нового, web приложения — это основное на чем Вам надо сосредоточиться,… подумайте дважды. Можно с уверенностью утверждать, что в обозримом будущем массового нашествия пользователей не ожидается. Вместо этого этого следует готовиться к медленному увеличению количества посетителей, с возможным пиком увеличения их числа (прим. переводчика: хабраэффект например). Но сосредотачиваться на архитектуре и масштабируемости Вашего приложения до миллионов пользователей — не очень хорошая идея. Миллионы это много. Скорее следует приготовиться к борьбе за первую тысячу пользователей. Возможно даже меньше, если Ваш сервис платный.

Мы выделили 5 основных пунктов, по которым можно определить юзабилити сайта. Список спорный и в основном касается продающих сайтов. И да, эти пять пунктов — среднее арифметическое опыта, полученного при обработке заявок на конкурс «Юзабельный вебпроект». Думаете, мы раздали слонов и забыли?


_{оригинал картинки}

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

Ошибки, само собой, повторялись. Голова пухла, а мы продолжали писать одинаковые комменты. Результатом марафона стал ниже приведенный чеклист.

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

Разбирая код очередного проекта внутри тега head наткнулся на интересный код:

<!--[if lt IE 9]>
<script src="http://ie7-js.googlecode.com/svn/version/2.1(beta3)/IE9.js"></script>
<![endif]-->

Только одно слово «IE9» меня пустило в замешательство. Первое что пришло мне в голову — это то, что при помощи этого .js кода браузеры под печальным клеймом Internet Explorer можно заставить работать используя свойства многообещающего IE9. Больше всего я ожидал что будут доступны свойства CSS3.0, но не тут-то было!

Summary

Announced: 2010-05-20
Credits: 80sec
Affects: сайты на ngnix+php с возможностью загрузки файлов в директории с fastcgi_pass

Background

Зачастую How-To по настройке связки nginx с php-fpm / php-cgi есть подобные строчки:

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    include fastcgi_params;
}

В вашей системе время играет важную роль? Ваши пользователи/компоненты распределены по территории всего земного шара, или хотя бы нашей необъятной родины? Значит, вам нужны часовые пояса. Что ж, это просто. Самое сложное, что вам придется сделать — не запутаться. Об этом мы с вами и поговорим. Для начала вам нужно научиться правильно думать. Думая правильно, все остальное будет для вас либо самоочевидным, либо достаточно простым.

Начнем с часов. Все мы привыкли определять время, глядя на часы на стене. При работе с часовыми поясами такое время называется Wall clock time. В принципе, ничего плохого в нем нет, только в разных местах земного шара в один и тот же момент времени часы показывают разное время. Если задаться целью, можно придумать алгоритм перевода wall clock time одного часового пояса в wall clock time другого. Обычно надо прибавить/отнять разницу в часах между часовыми поясами, кроме (внимание) моментов перехода на летнее/зимнее время. Вот когда начинается переход, вычисления становятся по-настоящему сложными.

Нам же нужно что-то простое и пуленепробиваемое, как… целое число.

Приветствуем всех посетителей, Habrahabr.
Продолжаем публиковать видеоматериалы, которые могут вам быть интересны.
2 года назад, одному из наших журналистов удалось побывать на заводе «Ангстрем».
Смотрите видеоотчет.



P.S. Качество картинки немного страдает, т.к., к сожалению, исходник сохранить не удалось!

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

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

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

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

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

Перевод статьи Тима Ферриса из его блога.


(Учебник Дзюдо Окано Исао, который я использовал для изучения японской грамматики)

Изучение языка не должно быть сложным.

Принципы когнитивной нейронауки и управления временем могут быть применены для достижения свободного владения языком на разговорном уровне (в данном случае определяется как 95%+ процентов понимания и 100% выразительных возможностей) в течение 1-3 месяцев.

Всегда нравилась идея онлайн-мониторинга чего-либо на карте. И вот представилась возможность сделать нечто подобное.
Процессом и результатом разработки хочу поделиться с сообществом.