3500 иконок готово. Можно сказать спасибо. После выпуска 3000 иконок FatCow прошел почти год, страницу посетило 700к посетителей. Пошел пятый год рисования. Находить удачные метафоры становится сложнее. Пытаемся охватить набор метафор, который нужен для специфичного софта и узконаправленных сайтов.
Чтобы дойти до 4000 иконок, работы хватит до апреля 2014 года. Потом укрупняем палитру или уходим в 5000. То есть по многочисленным запросам пользователей помимо 16-го и 32-го размера намерены освоить 48x48 и 96x96. В таком случае до середины 2015-го года нарисуем первую «крупную» тысячу.



Пятилетку за четыре года, кота за день. Чтобы понять, какие именно 500 метафор было положено в основе дополнительной эмиссии, смотрим сотканный kreol2013 надстройкой над программой KhodeN «ковер»…

Ощутимая часть электроэнергии в здании затрачивается на освещение. При этом мы часто освещаем пустые помещения и не выключаем свет днём, когда и так ярко.

У нас в КРОК непосредственно на самом офисе обкатываются системы, которые мы собираемся ставить заказчикам, поэтому поле для эксперимента было отличным.

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

Сразу покажу результат: в итоге мы получили экономию 45% на этаже площадью чуть более 1300 квадратных метров. Это с учётом человеческого фактора (выборочного отключения автоматики для собственного комфорта). Конечно, экономия получается не только за счет управления освещением, но и за счет замены светильников и общей модернизации освещения. Итого, срок окупаемости системы с учётом всего железа и работ – 5 лет. Измерение проводилось со 2 ноября 2012 года по 30 марта 2013 года (летом при большем световом дне питания потребуется ещё меньше, то есть результаты будут лучше).


Диаграмма оптимального режима работы искусственного освещения в типовом помещении с окнами (вертикаль – интенсивность свечения ламп, горизонталь — часы).

Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

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

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.

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

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



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

Доброе время суток, дорогие хабравчане! Данная статья является продолжением топика, и в ней хотелось бы начать обсуждение стадии создания требований. Если вы успешно справитесь с этой стадией процесса, вы получите отличный продукт, счастливых заказчиков и удовлетворенных разработчиков. В противном случае вам грозит непонимание, разочарование и разногласия.

Стадию создания или разработки требований условно можно разделить на 4 этапа.

Как российскому стартапу попасть в американский бизнес-акселератор? Что делать, куда обращаться, как готовиться? Какие преимущества это дает? Под катом немного полезной информации из личного опыта.

Мы запустили TradingView полтора года назад. Со временем стало понятно, что самостоятельные попытки пиара слишком дорого обходятся и не приносят ожидаемого результата. Идеальным вариантом было попасть на акселерационную программу, что мы и сделали, накопив немало интересного опыта в процессе.

Маркус «Notch» Перссон (автор всем известного Minecraft) в эти выходные запустил очередное свое развлекательное детище — смесь абстрактной аркады и клавиатурного тернажера. Имя этого чуда — Drop. Игра сделана на Unity3d, полностью бесплатна. Гипнотическая музыка и визуальные эффекты доставляют. Похоже, Нотч в клубе любителей слепого десятипальцевого метода и в легкой форме проводит агитацию.
p.s.: если нажимать пробел в процессе игры, то это дает бонус к набраным очкам.
p.p.s.: для игры необходим unity-плеер для браузера, можно взять тут

Собственно, вот ссылка на игру.

Сегодня официально представлена продвинутая версия научного поисковика Wolfram Alpha Pro. Это самый значительный апдейт за всё время существования поисковой системы. Хотя её и раньше трудно было назвать «поисковой системой», а сейчас это вообще нечто фундаментально иное.

Итак, на что способен Wolfram Alpha Pro за пять долларов в месяц?

После приобретения цифровой мыльницы у меня возникла необходимость каталогизировать отснятые файлы хотя бы по временам года. Но, как оказалось, после копирования с камеры дата изменения файла устанавливается в дату копирования и потом для того, чтобы узнать реальное время съемки, необходимо смотреть EXIF информацию или атрибуты файлы. Конечно, любая уважающая себя программа по просмотру файлов умеет извлекать из EXIF дату съемки, но мне данный способ неудобен.
Вот я и решил написать небольшую программу на C# которая ищет *.jpg файлы в текущем или указанном каталоге, извлекает время съемки и, в случае если это время не совпадает с временем изменения файла, то устанавливает это время согласно дате и времени съемки. Надеюсь, найдутся те, кому она пригодится.
Да, возможно есть графические программы в которые встроен аналогичный функционал, но я еще преследовал цель написать чего-нить на C#

После трёх месяцев тестирования компания BitTorrent запустила сервис BitTorrent Sync для синхронизации файлов и резервного копирования по протоколу BitTorrent между произвольными устройствами.

Chrome Logger это Google Chrome расширение для отладки серверсайд приложений в консоли хрома.

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

Инструкции по применению инсайд.

Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

Большинство статей в наш блог пишут разработчики. Мы решили исправить эту несправедливость и добавить немного DevOps. Сегодня поговорим о важном ― о бэкапах.
Так как Badoo активно развивается и количество сотрудников постоянно увеличивается, мы пришли к выводу, что централизованное резервное копирование гораздо удобнее, чем частичное копирование и хранение информации в различных местах.
В статье мы рассмотрим, как различными способами «забэкапить» довольно большое количество рабочих станций с помощью одного хранилища, не прибегая к серьёзным вложениям и избегая громоздкой реализации.
Заранее оговоримся, что бэкап не охватывает 100% сотрудников, так как не все хранят свои данные на локальных машинах, поэтому у нас не было цели сделать бэкап обязательно-принудительным.
Одной из основных сложностей централизованного бэкапа стало то, что сотрудники используют разные операционные системы.

Как же мы смогли собрать всех на одном сервере?

Айра Гас Хант (Ira Gus Hunt), действующий Директор по технологиям ЦРУ, рассказывает о своем видении Big Data на службе ЦРУ, а также возникающие при этом задачи и методы их решения. Выступление состоялось на конференции GigaOM Structure:Data 2013, проходившей 20 марта в Нью-Йорке. Как говорят очевидцы это было одно из самых интересных и запоминающихся выступлений.

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


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

Давайте остановимся на каждой функции поподробнее

Добрый день, Хабр!

Мой предыдущий перевод статьи про аппаратное ускорение в Android вызвал бурное обсуждение в комментариях, основным мотивом которого был вопрос «так почему же тормозит Android?». Аналогичная ситуация наблюдается по всему интернету, и потому я привожу ниже еще один очень интересный и свежий перевод (снова из Google+), где автор Andrew Munn (о нем ниже) анализирует настоящие причины тормозов Android. С удовольствием прочитал этот пост сам и горд возможностью первым поделится им с хабрасообществом.

Предисловие

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

Начало

В начале года вызвался я решить непрофильную задачу — создать для нашей организации информационную систему. Сейчас решение более-менее обрело очертания, попробую поделиться опытом.

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

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

Как это всегда бывает, я пришел совсем не с этой идеей — хотелось, грубо говоря, сделать свой ВКонтактик для улучшения информированности друг о друге. Идея в умах начальства трансформировалась и выстрелила в меня этим проектом — мол, здорово, обязательно сделаем, но у нас годовые отчёты на носу, можно ли эту информацию в такую систему забить? Делаю вид "лихой и придурковатый", отвечаю утвердительно и иду изучать материальную часть.

Задача

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

Разработчик и дизайнер Питер Ноэджл опубликовал «Шпаргалку по графическому дизайну для Android». В ней практически все, что вам необходимо знать для создания графических элементов приложений и оформления страниц в Google Play.

Тут описаны размеры, DPI, цвета, соглашения по именам и много другой важной информации.

Кроме того даются ссылки на все важные ресурсы, такие как стандартные гайдлайны и инструменты, шаблоны и заготовки для Photoshop.

Добрый день, уважаемые хабрачитатели! Сегодня я расскажу Вам о тернистом пути, который прошел я, чтобы стать фрилансером. Расскажу свою историю, историю программиста, который когда-то почти отчаялся от безысходности и не востребованности профессии программиста как таковой, но пережил этот непростой этап своей жизни.

В процессе разработки многокомпонентной системы автоматизированного тестирования сканера безопасности мы столкнулись с проблемой контроля целостности кода отдельных тестовых функций и проведения ревизий.

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

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

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

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