Я не умею программировать на объектно-ориентированных языках. Не научился. После 5 лет промышленного программирования на Java я всё ещё не знаю, как создать хорошую систему в объектно-ориентированном стиле. Просто не понимаю.

Я пытался научиться, честно. Я изучал паттерны, читал код open source проектов, пытался строить в голове стройные концепции, но так и не понял принципы создания качественных объектно-ориентированных программ. Возможно кто-то другой их понял, но не я.

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

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

Если говорить об операторах большой тройки и «стандартных» мобильных сетях (тех, в которых работают телефоны с обычными сим-картами), у каждого оператора есть как минимум три сети:

• Сеть 2G GSM-900 Mhz
• Сеть 2G GSM-1800 Mhz (DCS)
• Сеть 3G UMTS-2100 Mhz (WCDMA)

Распределение частот можно посмотреть вот на этой грандиозной картинке (клик на ней откроет полноразмерную картинку в новом окне).


Источник: www.exclusive-comfort.ru/faq-chastoty-svyazi-gsm.shtm

На этой картинке нет ещё одной сети — UMTS-900 Mhz. Это очень загадочная и интересная сеть. Вы не найдёте ни одного упоминания UMTS-900 на сайтах операторов, однако у Мегафон и МТС эти сети работают во многих местах Москвы и Подмосковья.

Начинаю выкладывать конспект книги «Элементы опыта взаимодействия», которая обязательна для прочтения всем кто занимается проектированием веб систем с которыми взаимодействуют пользователи.

Конспект приправлен моими мыслями, выкладывать буду по уровням, всего их 5:
1.Уровень стратегии
2.Уровень набора возможностей
3.Уровень структуры
4.Уровень компоновки
5.Уровень поверхности

Привет!

Ребята с ресурса Data Visualization собрали несколько очень интересных решений для представления данных:



Datavisualization.ch Selected Tools

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

Datavisualization.ch является одним из ведущих ресурсов в интернете, рассказывающих о визуализации данных и инфографике. На сайте обсуждаются и исследуются интересные и инновационные идеи в этих областях.

Привет, хабр!

UPD: третья часть цикла.

Это вторая статья цикла про QScintilla. Первая здесь. Для начала хочу сказать огромное спасибо всем, кто вывел меня из кармоямы! А теперь можно начать. Что мы сегодня будем делать? Мы напишем лексер для Assembler'а! «В коробке» его нету — не беда, напишем сами! Процесс довольно длительный, поэтому я буду немного меньше расписывать и комментировать. Тем более я не знаю язык ассемблера, так что лексер будет до ужаса примитивный и будет разрисовывать только команды и комментарии.

Как сказал Гагарин — «Поехали!»

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

Но помимо всех этих способов можно ещё сделать вот так:

sleep 25m ; xmessage 'Hey! :)'

Всего две команды, которые довольно легко запоминаются.

Вместо xmessage может быть, разумеется, что угодно ещё. Например:

sleep 8h 30m ; mplayer /home/user/Music/pink_floyd-the_happiest_days_of_our_lives.flac

Впрочем, тут надо учитывать, что команда не будет выполнена, если вы закроете терминал. Если же необходимо, чтобы команда всё-таки выполнилась, то есть несколько способов это сделать.

Надавно была опубликована библиотека node-fibers, вносящая в nodejs и v8 поддержку замечательного fiber/coroutine — тоесть, возможность использовать yield.
Параллельно, на nodejs groups прошел целый ряд обсуждений на тему всевозможных вариантов упрощения асинхронного синтаксиса.

Вдохновившись возможностями, которые дают «волокна», я написал библиотеку node-sync, которая делает разработку в асинхронном окружении nodejs значительно удобнее, а код — нагляднее.

Синопсис

// Обычная асинхронная функция, вызывает callback с результатом через 1 сек
function someAsyncFunction(a, b, callback) {
    setTimeout(function(){
        callback(null, a + b);
    }, 1000)
}
// Вызываем эту функцию синхронно, используя Function.prototype.sync(),
// работающий по тому же принципу, что и call()
// на этом моменте текуший поток "зависнет" на секунду, пока функция не вернет значение
var result = someAsyncFunction.sync(null, 2, 3);
console.log(result); // "5" через 1 секунду

Среди всей этой шумихи по поводу авторских прав есть один забавный пример — это крайний случай использования копирайта, который породила AT&T где-то в 1980-х. Речь идёт о программе /bin/true. Это пустая программа, которую обычно используют только для того, чтобы писать бесконечные циклы (while true do ...) в шелл-скриптах. Программа «true» не делает ничего, а только завершается с нулевым кодом. Такого поведения легко добиться — достаточно просто создать пустой файл и сделать его исполняемым, что и делали создатели первых Unix-систем. Пустой файл интерпретируется как шелл-скрипт, который не делает ровным счётом ничего. А, поскольку у него это вполне успешно получается, шелл возвращает нулевой код завершения. Но юристы AT&T решили, что это не помешает защитить копирайтом.

Пока компании вроде Google и Microsoft активно рассказывают простому пользователю о счастье, которое ожидает их на облачных сервисах, я хочу поделиться другой стороной облаков — счастьем для разработчиков и тестировщиков ПО. За те несколько лет, в течение которых я руковожу группой тестирования Parallels Plesk Panel, была собрана неплохая коллекция лайфхаков по использованию облака для наших целей.

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

С преамбулой вроде всё. Любопытных приглашаю под кат.

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

hg clone A B

mercurial сначала пытается создать жесткие ссылки для файлов внутри папки .hg в новом репозитории. Это ускоряет клонирование и экономит место на жестком диске.

Жесткие ссылки поддерживаются файловыми системами Linux и Windows NTFS. Для файловых систем, которые не поддерживают жесткие ссылки (например Windows FAT), а также при клонирование через http/https или ssh с удаленного сервера mercurial полностью копирует все файлы.

Размеры объектов в Java уже обсуждались на Хабре, например, здесь или здесь. Мне бы хотелось подробнее остановиться на размерах многомерных массивов — простая вещь, которая для меня стала неожиданной.

Оптимизируя вычислительный алгоритм по памяти, я наткнулся на то, что при определённых (вполне разумных) входных параметрах создаётся массив float[500][14761][2]. Сколько он может занимать в памяти (на HotSpot 1.6.0_26 32bit, если кому интересно)? Я примерно прикинул, что 500*14 761*2*sizeof(float) = 500*14 761*2*4 = 59 044 000 байт плюс какой-то оверхед. Решив проверить, как на самом деле, я воспользовался Eclipse Memory Analyzer (невероятно волшебная вещь, рекомендую!) и обнаружил, что «Retained Heap» для этого массива составляет 206 662 016 байт! Неплохой оверхед — 350%. Посмотрим, почему так получилось.

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



Разработкой новой главной занималась довольно большая команда: в нее входили дизайнеры, специалисты по юзабилити и, конечно, разработчики, среди которых я и note.

— Какое отношение имеет морская свинка к морю?
— Примерно такое же, как утконос к проектированию дирижаблей.

Введение.

Я имею обыкновение во время прогулок прокручивать информацию из нескольких источников, сопоставляя куски. Одна из любопытных находок – почти полное соответствие статистических наблюдений Демарко и Листера в «Peopleware» и теоретических выкладок Голдратта в «Критической цепи».

Осенью 2011 я крутил в голове:
[1] «Стоя на плечах гигантов» Эли М. Голдратт © Eliyahu M. Goldratt, 2008
[2] «Производственный менеджмент: управление потоком» Одед Коуэн, Елена Федурко
[3] «История одной доски» (http://cartmendum.livejournal.com/tag/theboard).

Далее хотелось бы написать: «Как вдруг…», — но это будет неправдой. Это случилось не вдруг. Мне понадобилось пару недель, но, в конце концов, в голове сложилась достаточно цельная картинка.

За что именно я зацепился:

• Таичи Оно (Öno Taiichi) не понимал, почему его система работает.
• Существует несколько разных типов производственных потоков – V, A, T, I. Каждый тип потока ставит особые задачи.
• Неудачи внедрения доски Максима Дорофеева в некоторых подразделениях
• Ряд компаний не смог внедрить систему Тойота, несмотря на все приложенные усилия.
• Система Тойота и система Форда основывается на одинаковых принципах, но прикладные решения ограничены определенными типами производства.

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

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

Когда в детстве мне надо было соединить несколько деталей из разных конструкторов, обычно приходилось пользоваться пластилином. Не самая удобная штука, но ничего лучшего не находилось — настоящие “взрослые” инструменты были слишком велики, тяжелы и недоступны, а что такое скотч, в 80-е было известно лишь избранным. Современным детям повезло куда больше. F.A.T. Lab совместно с Sy-Lab создали набор высококачественных 3D-моделей коннекторов, с помощью которых можно соединять между собой детали десяти популярных детских конструкторов — Free Universal Construction Kit.

Пару лет назад я сильно заинтересовался UX и всем, что с ним связано. Постепенно пришло понимание, насколько важна визуализация информации, особенно сейчас. Прочитав Тафти, Кливеленда и Бертена, просто невозможно не думать в этом направлении. Постоянно приходят в голову идеи, как сделать вещи (в частности, в нашем продукте) более визуальными, более понятными.

Ниже я попытался показать, почему визуализация информации важна, рассказать о ее базовых принципах и показать несколько классных примеров. Заранее прошу прощения за парочку скучных определений и отсутствие шуток в статье. Это сделано намеренно. Статья дэдли сериоус.

И, как обычно, прощу прощения за объем статьи. Но, надеюсь, вам будет интересно дочитать до конца.

По следам недавних топиков, а также постоянных рассказов в стиле «мой стартап не взлетел, потому что его зохавала лапша из callback-ов».

Как раз недавно я закончил небольшой проект (ссылку не даю, чтобы не заподозрили — кому надо см. профиль), полностью и на всех этапах написанном только на JS, и притом полностью асинхронный. Разумеется, я столкнулся с пресловутой проблемой «лапши». И, вы не поверите, совершенно спокойно решил её без всяких там фреймворков и хитрых приемов.

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

Недавно натолкнулся на хорошую и краткую презентацию по GTD от Persuasive Technology Lab (Stanford). Эта тематика как и любому гику мне близка и интересна, книг было прочтено много, опыт работы есть уже значительный, в итоге выработался некий концепт того, как я считаю правильно не только работать, но менять свои привычки, который сильно пересекается с тем что я прочитал в презентации. Далее перечислены ошибки, которые мы обычно совершаем в попытке изменить свое поведение, привычки и жирным выделено их решение. На мой взгляд этот список полезен и при решении любых других задач.

1. Опираться на силу воли для долгосрочных изменений.
Представьте что силы воли просто нет. Это первый шаг к лучшему будущему.

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

Как это писалось

Одним долгим зимним вечером моя жена играла в Bookworm adventures, и периодически пинала меня по поводу составления слов подлиннее из имеющихся букв. Быстрый поиск по интернету страничек, позволяющих составлять слова из набора букв дал кучу сайтов, которые пытаются делать это на серверной стороне, и один, который делает это на клиентской ява-апплетом. Те, которые составляют слова мощностями сервера либо имеют ограничение на размер набора букв (обычно, почему-то в 8), либо глубоко задумываются, если им послать набор «abcdefghijklmnopqrstuvwxyz». Ява-апплет же имел ограничение в 12 букв, работал шустро и почти подходил (в игре предлагаются 16 букв для составления слов).

Механика free-to-play, давно уже зарекомендовавшая себя в онлайн-играх на PC, за последний год получила широкое распространение и на мобильных платформах. Именно бесплатные игры с возможностью докупки внутриигрового контента по статистике приносят наибольшую прибыль. Как сделать free-to-play игры успешными, чего хочет их аудитория и чем F2P кардинально отличаются от других игр, читайте в нашем материале по мотивам публикаций креативного директора и гейм-дизайнера Паскаля Лубана (Pascal Luban).



Вообще, free-to-play (F2P) игры – это не какой-то новый жанр, это целая революция в игровой индустрии. Появление F2P повлияло на большинство аспектов и факторов в маркетинге, издании, дистрибуции, дизайне и разработке.

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