Большинство приложений провальны. Эта жестокая реальность приводит многих разочарованных разработчиков к заключению, часто подсознательному, что преуспевание в App Store — всё равно, что разбогатеть на «золотой лихорадке»: нужно быть чертовски удачливым.



Идея «удачи» — опасное успокоительное средство, облегчающее боль неудачи. А боль — это хорошая вещь. Она показывает, что что-то идёт не так. Если моё приложение потерпело крах, я хочу знать почему. Вместо того, чтобы обвинять мироздание, почему бы не посмотреть, что ребята из tap tap tap и Tapbots делают для того, чтобы снова и снова достигать успеха.

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

«1. Держите сервера за границей»
(с) 9,5 правил ведения безопасного бизнеса в России

Вводная часть.

Мы — маленькая компания из 10 сотрудников, половина из которых периодически работает удаленно.
Что мы имели изначально: сервер с Windows и терминальным доступом, который стоял в офисе. У всех пользователей были ноутбуки. Никакой особо конфиденциальной информации у нас нет, за исключением важной для бизнеса информации.
В один прекрасный момент меня окончательно «добила» паранойя и было принято решение вынести сервер за пределы офиса.

Феерическая расстановка точек над i в вопросе удаления файлов из переполненной директории.

Прочитал статью Необычное переполнение жесткого диска или как удалить миллионы файлов из одной папки и очень удивился. Неужели в стандартном инструментарии Linux нет простых средств для работы с переполненными директориями и необходимо прибегать к столь низкоуровневым способам, как вызов getdents() напрямую.

Для тех, кто не в курсе проблемы, краткое описание: если вы случайно создали в одной директории огромное количество файлов без иерархии — т.е. от 5 млн файлов, лежащих в одной единственной плоской директории, то быстро удалить их не получится. Кроме того, не все утилиты в linux могут это сделать в принципе — либо будут сильно нагружать процессор/HDD, либо займут очень много памяти.

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

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

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

В этом посте пойдет речь об одной интересной фичи в C++11, которая называется делегирующие конструкторы (delegating constructors): почему она интересна, и как ее можно применить для более эффективного управления ресурсами, т.е. реализации идиомы RAII.

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

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

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

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

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

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



Тогда в моей ответственности был заказной проект с чёткими требованиями, «моя» команда, которой я ставил задачи, защищал и оберегал от внешнего мира, расписание, которое я составлял и отстаивал в дискуссиях с руководством и заказчиком. С заказчиком, как и с руководством, я общался с позиции команды и отстаивал её интересы: чтобы сроки были достаточны, чтобы новые требования не появлялись «ниоткуда», чтобы претензии к качеству имели под собой реальные основы и так далее. Отношение с командой при этом было, на мой взгляд, близкое к идеалу. Конечно, встречались и конфликты и разногласия, но, в большинстве случаев, они разрешались мгновенно и безболезненно.

Внутренняя система инспектирования исходного кода Critic, применяемая в Opera Software, вчера вечером была выложена на Github под лицензией Apache License 2.0.

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

Скачать исходные коды Critic можно здесь: github.com/jensl/critic.

^Assorium

На Хабре публиковалось несколько статей с алгоритмами и скриптами для выбора доминирующих цветов на изображении: 1, 2, 3. В комментариях к тем статьям можно найти ссылки ещё на десяток подобных программ и сервисов. Но нет предела совершенству — и почему бы не рассмотреть способ, который кажется самым оптимальным? Речь идёт об использовании кластеризации методом k-средних (k-means).

От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).

---

Однажды меня спросили: «Как ты решился пойти на такой страшный риск — писать Storm одновременно с запуском стартапа?» (Storm — фреймворк для распределённых вычислений в реальном времени). Да, пожалуй, со стороны создание такого крупного проекта для стартапа кажется крайне рискованным. Тем не менее, с моей точки зрения это вообще не было рискованным делом. Трудным, но не рискованным.

Я использую стиль разработки, который сильно уменьшает степень риска таких больших проектов, как Storm. Я называю этот стиль «разработкой через страдание». В двух словах: не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий. Этот совет применим как к большим, архитектурным решениям, так и к маленьким повседневным задачам. Разработка через страдание существенно уменьшает риск, гарантируя, что вы всегда работаете над чем-то важным, и что вы хорошо разобрались в предметной области, прежде чем вложить в решение много сил.

Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».

Вы слышали, что в некоторых компаниях сотрудникам разрешается 20% времени работать над собственными проектами? Оказывается, существует компания, где этот принцип возвели в абсолют. Представьте, что 100% рабочего времени вы можете работать над любыми проектами, какими пожелаете. Менеджеров не существует вообще, никаких отделов и начальников. Структура компании — плоская, все сотрудники равны между собой и добровольно группируются по интересам. Выживают те проекты, которые привлекают больше сотрудников.

Звучит как утопия? Знакомьтесь с принципами менеджмента в компании Valve, которая занимается разработкой компьютерных игр (Half-Life, Portal, Steam).

На одной улице в Бердичеве жили трое портных. У первого была вывеска: “Лучший портной в городе”, у второго — “Лучший портной в мире”, а третий написал: “Лучший портной на этой улице”.

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

Вы никогда, НИКОГДА не станете богатым от экономии на покупках в супермаркете!

Сотни миллионов людей в мире экономят как на покупках, так и на самих супермаркетах, не говоря уже о миллионах голодных, “экономящих” на еде вообще. Можно предположить, что достаточно большая часть экономящих людей попадается на удочку относительно больших чисел, получаемых умножением грошей на 20-30-40 лет… без какого-либо положительного финансового эффекта. Причина элементарна: экономический план на десятки лет — это оксюморон. Такой план не учитывает множество факторов, влияние которых весьма значительно и на более короткие сроки, поэтому он может называться мечтой, фантазией, как угодно еще, только не финансовым планом. Кризисы, биржевые скачки, инфляция, изменения в жизни, в работе, в уровне доходов, политической обстановке… да одна только кратковременная флюктуация в курсе валют может мгновенно уничтожить нажитое непосильным трудом (как и наоборот, кстати). Вы не разбогатеете за 20 лет, отказывая себе в шоколадках, или не тратя деньги на сигареты, или “собирая бутылки”. Вернее, не так. Ваш шанс разбогатеть за NN лет совершенно не зависит от ваших сегодняшних действий и еще меньше зависит от мелочей. А все потому, что

«Нечётный воин 3» – сайд-проект группы «Би-2», где Лёва и Шура выступают в роли саундпродюсеров. После успешного краудфандингового проекта по выпуску альбома Spirit (на «Планете» было собрано более 1 260 000 рублей), «Би-2» решили таким же образом выпустить третий по счету «Нечетный воин». Музыканты очень верят в крауд-схему и считают ее идеальным вариантом взаимодействия артистов и поклонников.
Концепция «Нечётного воина» – объединение известных артистов с целью создать нечто абсолютно новое. На уже вышедших альбомах проекта отметились Диана Арбенина («Ночные снайперы»), Brainstorm, «Агата Кристи», Линда, Андрей Макаревич, Инна Желанная, Сергей Мазаев («Моральный кодекс»), Алексей Кортнев («Несчастный случай»), Эдмунд Шклярский («Пикник»), David Brown (Brazzaville) и многие другие.
Заявленная финансовая цель проекта — 950 000 рублей. За первый день после старта собрано более 50 000 рублей.

Комманда git up (аналог svn up) добавляется так:

git config --global alias.up '!(git add . && git stash && git pull --rebase >&2) | grep -v "No local changes to save" && git stash pop'

git up при надобности ныкает все ещё незакоммиченные изменения в stash, обновляет локальную ветку до свежайшей и восстанавливает локальные изменения назад. В том числе переносит ещё неотправленные локальные коммиты в самый конец, делая историю линейной как в Subversion, т.е. избегая лишних веток и merge-коммитов.

Самая большая коллекция флагов: 2400 пиктограмм размерами 16×16, 24×24, 32×32, 48×48 и 64×64. Есть государственные флаги всех стран, плюс бонусы: Англия, Абхазия, Нагорный Карабах, Красный крест, Южная Осетия, Сомалиленд, флаг Марса, НАТО и проч.

Все иконки в двух вариантах: стандартный и глянцевый.

Скачать:
www.gosquared.com/download/pixels/flags.zip

Лицензия MIT (GPL-совместимая), разрешает использование иконок в коммерческих проектах.

Всем привет!

В этом посте я хочу поделиться видением видеороликов, “которые продают”.

Мы в Alconost занимаемся производством рекламных видеороликов для софта и интернет-сервисов. В течение нескольких лет работы мы постепенно накапливали опыт, который в итоге оформился в то, что мы называем “философией продающего видео”

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

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

Наткнулся на очень простой в реализации, но интересный rollover-эффект для кнопок на CSS. Автор — некий японец ksk1015.



Демонстрация эффекта и процесс написания.