Эта статья предназначена для тех, кого бесят мильён левых служб и драйверов, которые ставят любые виртуалки. Тем, кто будут ставить доп. пакеты Node.js
Все остальные могут скачать скомпилированный Node.js node-js.prcn.co.cc
Или же установить Node.js из-под виртуалки nodejs.ru/25

Прошу под кат

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Знакомый, в глаза не видевший Linux, но заинтересовавшийся опенсурсом, после выхода Ubuntu 10.10 попросил написать ему, "чем хорошо, чем плохо, какие осложнения, какие тонкости, как наладить отношения с вин7", чтобы он мог решить, нужно ли ему это счастье.

Сначала подумал "зачем буду писать текст, когда наверняка его уже сто человек написали — быстро нагуглю, пошлю ссылку, а потом уже на конкретные вопросы отвечать буду". Но затем обнаружил, что по запросам вроде "миграция на ubuntu" вываливаются гигантские мануалы с тонкостями настройки compiz, а недлинный текст для "неопределившихся" быстро найти не получается ни в интернете вообще, ни на ubuntu.com и ubuntu.ru (то есть все как и писал в предыдущем посте), ни на Хабре — вот и подумал, что пусть теперь хотя бы на Хабре будет.

Участники "Убунтариума" вряд ли узнают из текста что-то новое, зато они могут дополнить его в комментах (не претендую на звание гуру, так что много важного наверняка упустил), и тогда люди, которые позже введут в гугл что-то вроде "переход на ubuntu", найдут тут счастье.

Этим постом я начинаю серию статей, которые должны помочь каждому разработчику избавиться от велосипедов в своих последующих и текущих проектах. Усилить код и увеличить функционал. Каждый из нас хочет внести в свою программу нечто, что сделает ее богаче, но зачастую решение либо не находится, либо лень тратить время на поиски… Либо внутри сидит глупая уверенность что это можно реализовать быстро и не менее функционально. В любом случае я хочу чтобы каждый пробежался глазами по спискам библиотек, которые я вам предоставлю на суд, и чтобы у каждого эти библиотеки отложились в памяти. И когда их функционал пригодится в будущем, я очень надеюсь что вы вспомните этот пост и поищите эти библиотеки вместо того чтобы писать все новые и новые велосипеды, полные палок в колесах.
Начну я с оконных менеджеров.

Я часто слышал, как говорили: «Нет идей для проектов? Выйди из дома и поговори с реальным людьми, узнай их проблемы». Вот, собственно, я этим и занялся на досуге. Получилось ли из этого что-то интересное — судить вам.

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

Однажды мне понадобилось решить простенькую (как мне тогда казалось) задачу – в PHP-скрипте узнать длительность mp3-файла. Я слышал о ID3 тегах и сразу подумал, что информация о длительности хранится либо в тегах, либо в заголовках mp3-файла. Поверхностные поиски в интернете показали что за пару-тройку минут решить эту задачу не получится. Поскольку от природы я довольно любопытен а время не поджимало — решил не использовать сторонние инструменты а разобраться в одном из самых популярных форматов самостоятельно.

Если Вам интересно, что там внутри – добро пожаловать под кат (трафик).

Чем медленнее загружается и работает web-приложение, тем меньше пользователей захотят им воспользоваться. Google понимает это как никто другой, поэтому в созданном ими Web Toolkit особое внимание уделено скорости работы получаемых с его помощью web-приложений.

Статья рассказывает о том, какие приемы клиентской оптимизации используются в GWT.

В современном бизнесе принято полагаться на многозадачность, и оценка сотрудника как специалиста зависит от его способности выполнять несколько задач одновременно. IT-специалисты постоянно работают в нескольких проектах сразу. Всегда ли так было? Действительно ли многозадачность необходима? Какую реальную пользу она приносит? И есть ли ей альтернативы?

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

Другая точка зрения

Когда мы говорим об опыте, полученном при работе в рамках Agile или Scrum, то всегда камнем преткновения становится идея о том, что команда работает гораздо лучше и эффективнее, если у нее постоянный состав и ее члены не заняты в других командах. В этом нет ничего нового. У нас есть многолетний опыт создания групп специалистов для решения особо трудных проблем, особенно во времена кризиса. И в то же время наши организации пришли к модели, где мультиспециалисты заняты одновременно во множестве проектов. Фактически, это единственно решение, позволяющее справляться со множеством вещей сразу. Считается, что это наиболее эффективный способ использовать «ограниченные ресурсы», то есть когда у вас мало специалистов, но все они широкого профиля.

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

Прогресс не стоит на месте, люди ищут новые решения, и на JVM появляется всё больше интересных языков. Но «ядро» JVM сообщества — народ суровый, привыкший к серьёзным стандартам, и с высокими требованиями. Поэтому большинство новых языков так и висят «на периферии».

От других языков на JVM Scala отличается действительно основательным подходом — над языком работает лаборатория мощнейшего европейского института EPFL во главе с профессором Мартином Одерски, который также известен как дизайнер системы generic-ов из Java 1.5. Конечно, это не сравнить по объёму поддержки с серьёзными коммерческими конторами в роде Sun или Microsoft, поэтому язык развивался медленно и «пошёл в дело» совсем недавно:


Что в нём интересного?

Введение

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

Управляемая память в .Net поделена на стек и несколько хипов. Самые важные из хипов – это обычная (эфемерная) куча и LOH. Эфемерная куча – это то место, где живут все обычные объекты. LOH – это то место где живут большие (больше 85000 байт) объекты.

LOH обладает некоторыми особенностями:

• Объекты в LOH никогда не перемещаются
• LOH только растет и никогда не уменьшается (т.е. если объект собран сборщиком мусора, размер LOH все равно остается неизменным)
• Хип LOH освобождается только тогда, когда LOH полностью пуст

Из этих двух особенностей LOH происходят два важных следствия, про которые часто забывают:

• Память в LOH может оказаться фрагментированной. Т.е. происходит то, с чем так боролись в unmanaged мире: в какой-то момент у вас может быть 10Mb свободной памяти, но вы не сможете выделить память под объект размером 1Mb
• Если вы однажды выделили память под большой объект, а потом используете только маленькие, то вы фактически лишаете себя большого куска памяти. При чем, если у вас в LOH был список или хэш-таблица размером N, а вы добавили в него один элемент, то список реаллоцируется и растет в два раза, сответственно размер LOH составит как минимум 3*N (N – исходные данные, 2N – копия данных и резерв под новый размер). Следующий рост потребует в LOH непрерывный кусок памяти размером в 4*N, а так как такого куска в LOH у нас нет (есть только N), его придется позаимствовать из адресного пространства процесса. В итоге размер LOH вырастет до 7*N, и так далее.

Если вспомнить, что LOH аллоцируется кусками по 16Mb, то все происходящее покажется еще более разрушительными. С первым следствием можно бороться аккуратно переиспользуя объекты. Со вторым — не используя большие объекты. Получается как-то не очень, особенно если с большими коллекциями работать все-таки хочется. Посмотрим, что как можно решить эту проблему.

Быстро! Ответьте на следующий вопрос:

Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?

Согласно психологическим опросам среди разных групп, около 90% программистов отвечают «Выше среднего».

Очевидно, это не может быть правдой.

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

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

Время это не только физическая величина, но и психологическая

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

Примечание: ниже перевод презентации «High Performance Ajax Applications», подготовленной ведущим специалистом из Yahoo (а теперь уже из Apple) Julien Lecomte. В ней автор освещает некоторые аспекты оптимизации как JavaScript-приложений, так и веб-сайтов вообще. В целом, советов много, и почти все, действительно, по делу. Однако, встречается и откровенная реклама Yahoo :) Мои комментарии далее курсивом.

Часть 1. Разработка для высокой производительности

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

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

читать дальше на webo.in →