Доброго времени суток, всем! Кто-то умный, не помню в какой статье именно на Хабре, буквально недавно размышлял о процессе разработки с явным призывом автоматизировать все, что только можно автоматизировать. И лучше один раз потратить время на автоматизацию, чтобы потом экономить его на протяжении всего проекта.

У веб-разработчиков есть прекрасный инструмент для автоматизации массы задач, который называется Grunt. И моя страсть к таксономии заставила себя собрать огромную коллекцию почти из 100 ценных плагинов для этого сборщика. Думаю многие кто уже использует Grunt найдут для себя что-то нужное, а кто нет, глядя на возможности, получит хорошую мотивацию установить его и понять как эта штука работает.

А еще я выложил подборку на GitHub, чтобы каждый мог пополнить коллекцию.

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

• Введение
• Свойства особых точек
• Детекторы углов
  
  • Moravec
  • Harris
  • Shi-Tomasi
  • Förstner
  • SUSAN
  • Trajkovic
  • FAST
  • CSS
  • Детектор, основанный на глобальных и локальных свойствах кривизны
  • CPDA
• Выводы

Среди задач по программированию часто попадаются такие: дана последовательность однотипных элементов (обычно это числа), требуется за один проход по ней найти какую-нибудь характеристику (среднее квадратическое отклонение, количество минимальных элементов, непрерывный участок с наибольшей суммой...) Дополнительное ограничение — последовательность может быть очень длинной, и в память не поместится. Других ограничений на элементы последовательности, обычно, не накладывается.
С этими задачами всё, более или менее, понятно: нужно найти то, что на мехмате МГУ называют «индуктивным расширением» искомой функции, и реализовать её вычисление. Если найти не удалось (требуемый объём памяти слишком велик), то задача не решается.
Но попадаются и другие задачи. В них есть дополнительные ограничения на элементы последовательности в совокупности, и эти ограничения приходится существенно использовать для решения (и проверять их не надо). Простейшая такая задача выглядит так:

Задача 1. В последовательности записаны целые числа от 1 до N в произвольном порядке, но одно из чисел пропущено (остальные встречаются ровно по одному разу). N заранее неизвестно. Определить пропущенное число

Решение очевидно: просматриваем числа, находим их количество K и сумму S. По условию, N=K+1, значит, сумма чисел от 1 до N будет равна (K+1)*(K+2)/2, и пропущенное число равно (K+1)*(K+2)/2-S. Если вы почему-то боитесь переполнений, то работайте с беззнаковыми числами (там переполнения не страшны — но будьте осторожны при вычислении (K+1)*(K+2)/2 :) ), или вместо суммы ищите XOR всех чисел.

Ниже — вольный пересказ книги Running Lean, автор — Ash Maurya. Рейтинг Амазона — 4.8 из 5. Книга, насколько я знаю, на русский язык еще не переведена.

Здесь изложена суть книги в объеме меньшем 1% объема книги, по моей оценке. Все вопросы освещены так, как я их понял, что необязательно совпадает с тем, как их хотел донести автор.

Допускаю, что нарушаю чьи-то права: пересказ лицензии не требует, но иллюстрации взяты из книги. Автору я писал в попытке прояснить этот вопрос, но ответа не получил.

Блог автора кгиги: practicetrumpstheory.com.

Структура пересказа

• Введение в процесс Running Lean
  • Три важнейших методологии
  • Roadmap
• Описание процесса Running Lean
  
  • Составьте «План А»
    
    • Определите кто клиенты
    • Создайте бизнес-модели
    • Ранжируйте бизнес-модели
  • Протестируйте и измените план
    
    • Подготовьтесь к проведению экспериментов
    • Категории рисков и четыре фазы тестирования плана
      
      • Фаза 1. Поймите проблему
      • Фаза 2. Найдите решение
      • Фаза 3. Валидируйте качественно
      • Фаза 4. Верифицируйте количественно
• Три стадии стартапа
  
  • Соотношение трех стадий стартапа и четырех фаз тестирования плана
  • Держите правильный фокус
  • Привлекайте финансирование вовремя
  • Масштабируйте правильно

Работать где-то мечтают не все. Работать в компании Google мечтают многие, кто решил связать свою жизнь с IT.

Google — компания-гигант, одна из крупнейших IT-корпораций. Сотрудники такой компании нужны постоянно (новые области, текучка кадров).

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

Шаг 1 — резюме.

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

• e-mail, телефон для связи
• все места учёбы (ВУЗы), дополнительное образование
• Опыт работы*
• Личные качества (придумайте что-то оригинальнее отзывчивости, стрессоустойчивости, коммуникабельности)
• Хобби
• Reference — люди, которые могут дать вам рекомендации
• Знание языков

*Опыт работы в резюме для Google (и вообще для западных компаний) — это не только должность, компания, но и те успехи и достижения, которых вы добились на позиции. Если вы продажник — покажите цифры. Если программист — то как именно ваша работа улучшила работу компании. Работу рекомендуется указывать всю, а не только по профилю (если работали в МакДоналдсе, то даже такое стоит указать).

Что не нужно писать в своём резюме:

• Дату рождения, личные данные
• Есть ли водительские права
• Семейное положение
• Прочую «шелуху», которая только отвлечёт рекрутера

Каталог:
Один
Два
Три

Менеджер памяти (и связанные с ним вопросы контроллера кеша, менеджера ввода/вывода и пр) — одна из вещей, в которой (наряду с медициной и политикой) «разбираются все». Но даже люди «изучившие винду досконально» нет-нет, да и начинают писать чепуху вроде (не говоря уже о другой чепухе, написанной там же):

Грамотная работа с памятью!!! За все время использования у меня своп файл не увеличился ни на Килобайт. По этому Фаерфокс с 10-20 окнами сворачивается / разворачивается в/из трея как пуля. Такого эффекта я на винде добивался с отключенным свопом и с переносом tmp файлов на RAM диск.

Или к примеру μTorrent — у меня нет никаких оснований сомневаться в компетентности его авторов, но вот про работу памяти в Windows они со всей очевидностью знают мало. Не забываем и товарищей, производящих софт для слежения за производительностью и не имеющих ни малейшего понятия об управлении памятью в Windows (и поднявших по этому поводу истерику на пол интернета, на Ars-е даже был разбор полетов). Но самое потрясающее, что я видел всвязи с управлением памятью — это совет переместить pagefile на RAM-диск:

Из моих трех гигабайт под RAM disk был выделен один (на тот момент, когда на лаптопе еще была установлена XP), на котором я создал своп на 768МБ ...

Цель данной статьи — не полное описание работы менеджера памяти (не хватит ни места ни опыта), а попытка пролить хоть немного света на темное царство мифов и суеверий, окружающих вопросы управления памятью в Windows.

Всем привет.
Хочу поделиться своим опытом переезда в Нидерланды.

Краткое предисловие.

Все свои 25 лет я прожил в Киеве, закончил КПИ. На 3м курсе начал заниматься веб-разработкой — пилил сайты на Джумлах — Вордпрессах, рисовал дизайны и потихоньку изучал премудрости PHP и JS. Через 1.5 года устроился в киевский филиал Anzer IT Healthcare и, после года работы там, первый раз серьезно задумался о поиске работы за границей с переездом. Тогда я видел это как успешное продолжение карьеры, еще со школьных-институтские времен, видать, въелись наставления родителей.

Итак…

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

Приветствую уважаемое хабрасообщество!

Так как рекрутинг – это не только моя работа, но и увлечение, хочу поделиться с вами интересной, по моему мнению, информацией. Речь пойдет, простите за тавтологию, о самой речи – словах, которые мы с вами подбираем, выражая свои мысли в беседе с менеджером по персоналу.
Казалось бы – а что тут подбирать? Называем вещи своими именами и все. Работа скучная – «неинтересная», руководство непрофессиональное – «дилетанты», зарплата небольшая – «смешная», каждый сам за себя – «коллектив неслаженный».
Но не все так просто как кажется на первый взгляд.

Как учиться лучше и быть эффективнее: простые и полезные техники

Просмотрела курс на Coursera «Learning how to learn», который рассказывает, как лучше учиться, запоминать информацию и быть более эффективным, и составила список из 17 советов-приемов. Возможно, вы найдете их полезными.

Прошло некоторое время с тех пор, как я писал про Центрифугу в предыдущий раз. Произошло множество изменений за этот период. Многое из того, что было описано в ранних статьях (1, 2) кануло в лету, но суть и идея проекта остались прежними — это сервер рассылки real-time сообщений пользователям, подключенным из веб-браузера. Когда на вашем сайте возникает событие, о котором вам нужно моментально сообщить некоторым вашим пользователям, вы постите это событие в Центрифугу, а она, в свою очередь, отправляет его всем заинтересованным пользователям, подписанным на нужный канал. В самом простом виде это показано на схеме:



Проект написан на Python с использованием асинхронного веб-сервера Tornado. Использовать можно даже если бекенд вашего сайта написан не на Python. Хотелось бы рассказать о том, что Центрифуга представляет собой на данный момент.

Цель этой статьи — рассказать о возможностях платформы CUBA на примере создания небольшого полезного приложения.
CUBA предназначена для быстрой разработки бизнес-приложений на Java, мы уже писали о ней несколько статей на Хабре.

Обычно на платформе строятся либо реальные, но слишком большие и закрытые информационные системы, либо приложения в стиле “Hello World” или искусственные примеры типа “Библиотеки” на нашем сайте. Поэтому некоторое время назад я и решил попробовать убить сразу двух зайцев — написать для себя полезное приложение и выложить его в общий доступ как пример использования нашей платформы, благо предметная область простая и всем понятная.

Привет, читатель хабра.

Наверное, ты сразу спросишь меня: «Да кто ты такой, чтобы давать мне советы?». Итак, немного обо мне.

Первое мое общение с HTML и CSS было 10 лет назад, еще в школе, когда у меня только появился интернет, и я понял что тоже хочу делать странички, которые сможет увидеть весь мир. С тех пор у меня есть как минимум 5 полных лет опыта разработки сайтов по-взрослому. Сейчас я могу без лишней скромности сказать, что сверстал я уже пару сотен сайтов, большинство из которых, как ни странно, совершенно не совпадают с моими текущими требованиями к верстке.

Я не хочу рассказывать как надо делать, эта статья результат моего опыта и попытка написать рекомендации тем, кто только начинает, хотя и для матерых верстальщиков (слово режущие слух) здесь могут найтись интересные идеи.
Если ты заинтересовался прошу под кат…

Привет, Хабр! Решил побаловаться графоманством и поделиться результатом развлечения прошедших выходных (только эти выходные прошли давно и статья писалась гораздо дольше, чем развлечение. Как говорится, делу время — потехе час).

Я расскажу про так называемые алгоритмы расщепления (в частности, про DPLL-алгоритм), про теорему и числа Ван-дер-Вардена, а в заключение статьи мы напишем свой собственный алгоритм расщепления и за полчаса вычислений докажем, что число w(2; 5) равно 178 (первооткрывателям в 1978 году на это потребовалось более 8 дней вычислений).

Дисклеймер от автора (автор — девушка): Я не разрабатываю движки баз данных. Я создаю веб-приложения. Я участвую в 4-6 разных проектах каждый год, то есть создаю много веб-приложений. Я вижу много приложений с различными требованиями и различными потребностями хранения данных. Я разворачивала большинство хранилищ, о которых вы слышали, и несколько, о которых даже не подозреваете.

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

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

На MoscowJS приходят докладчики разного уровня. У некоторых за плечами опыт выступлений на крупных конференциях. Кто-то преподавал в ВУЗе или вёл тренинги. Многие выступают на публике в первый раз.

Мы помогаем ребятам подготовиться. Даём советы по контенту, организуем совместные прогоны. Качество доклада зависит от многих факторов. В первом приближении всё сводится к двум вещам:

• Как вы готовитесь к докладу;
• Как вы ведёте себя во время выступления.

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

1. Упарываться по хардкору
Это не ошибка, но очень характерная ситуация для IT-сферы. Пока другие стартаперы не имеют продукта, зато рассылают релизы со скриншотами, пьют смузи, выступают на конференциях и выставках, айтишники пишут код. Когда прототип собран и дело доходит до поиска инвестора, становится понятно, что пиар тоже был нужен. Вот только начинать его надо было месяца так два назад.

2. «Сам дурак»
Большая проблема — нежелание слушать мнение окружающих. Когда половина проекта готова и внезапно становится понятно, что проект нежизнеспособен, есть два варианта: резко меняться или сворачиваться. Знаете, что часто делают руководители IT-стартапов? Перестают слушать людей снаружи, превращают команду в секту и упорно допиливают продукт. Потому что полработы уже сделано.

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

От переводчика:

Привет, Хабр! Мы мы продолжаем делится с сообществом полезными материалами о разработке и дизайне. В этот раз команда TrackDuck подготовили перевод статьи Jeff Dickey о Angular, которая нам очень понравилась и в свое время заставила пристальней присмотреться к Gulp. Эта статья будет полезна разработчиками, которые хотят сэкономить время на рутинных операциях и построить качественные процессы при разработке веб-приложений. Мы активно используем Angular для разработки собственного продукта для визуального комментирования веб-сайтов, поэтому готовы ответить в комментариях на интересующие вас вопросы!

Я использовал Angular в довольно большом количестве приложений и видел много способов структурирования приложений с использованием этого фрэймворка. Сейчас я пишу книгу о проектировании Angular приложений c использованием MEAN стека, и больше всего исследований я провел в этом направлении. В итоге я остановился на довольно оригинальной структуре приложения. Я считаю, что мой подход более простой чем тот, что предложил Burke Holland.
Прежде чем начать, я хотел бы рассказать о существующем подходе к реализации модульности в Angular.

От переводчика: cоучредитель сервиса Freckle Time Tracking делится 5 самыми значимыми вещами, которые он узнал за 5 лет работы над сервисом:

1. Вы не «техническая компания», а компания, которая «делает клиентам лучше»

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