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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

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

Наткнулся на интересное интервью с сооснователем Google Ларри Пейджем. Мне оно показалось очень занимательным, и я старался как мог переводя его на русский язык, чтобы поделиться им с вами. Перевод может быть не очень точным, прошу за это прощения. Для свободно англо-читающей аудитории в конце поста ссылка на источник, в оригинале естественно можно получить больше удовольствия от прочтения. Если что-то из интервью вам придётся не по вкусу или вы не согласны с тем что говорит Ларри — не спешите минусовать, подумайте о том, что я всего лишь перевел это для вас. Tim — это интервьюер. Ну, поехали:



Tim: Google известна тем что поощряет своих сотрудников решать амбициозные задачи и делать большие ставки. Почему это так важно?
Larry Page: Я волнуюсь о том, что что-то серьёзно пошло не так с тем как мы управляем компаниями. Если вы читаете то что средства массовой информации пишут о нашей компании, или вообще о всей технологической индустрии — речь всегда идёт о конкуренции. Всё преподносится так как будто речь идёт о спортивном событии. Не легко найти примеры действительно впечатляющих вещей, которые были сделаны исключительно за счет конкуренции. Многие компании приходят в упадок со временем, потому что они имеют тенденцию делать в точности тоже что они делали раньше, всего лишь внося небольшие изменения. Это естественно для людей — заниматься чем-то в чем они точно уверены что не потерпят неудачу. Но просто постепенного улучшения недостаточно.
Таким образом огромная часть моей работы это сфокусировать людей на вещах, работая над которыми можно добиться чего-то более значимого чем просто постепенного улучшения существующего. Возьмём например Gmail. Когда мы выпустили её, мы были поисковой компанией — это был большой скачёк для нас выпустить почтовый сервис, не говоря уже о том что мы дали пользователям в сотню раз больше свободного места чем они могли получить где-либо еще. Это не что-то что могло бы произойти само собой если бы мы просто сосредоточились на постепенном улучшении.
Tim: Но вы же должны улучшать и ваши существующие продукты, верно?
Larry Page: Конечно. Но периодически, каждые несколько лет, вам следует работать над чем-то новым, что на ваш взгляд является поистине удивительным.
Tim: Теперь у вас есть отдельное подразделение называемое Google X, предназначенное для таких «moon-shot» проектов (прим. автора: не знал как это точно перевести поэтому так и оставил, здесь имеются ввиду революционные проекты вроде полётов на луну и т.п.), как например самоуправляемые автомобили. Почему вы решили что нужно учредить целый департамент для этого?
Larry Page: Я думаю нам необходимо делать прорывные вещи, а не просто улучшать то что есть и это касается всего нашего бизнеса. Но сейчас Google X делает вещи которые могут быть сделаны более независимо.
Знаете, у нас всегда есть такие споры: У нас есть все эти деньги, у нас есть все эти люди, так почему же мы просто не производим больше? Вы можете сказать что Apple делает очень небольшое кол-во вещей, и это довольно хорошо работает для них. Но я нахожу это неудовлетворительным. Я чувствую как много возможностей использования технологий для улучшения жизни людей сейчас существует в мире. В Google мы нацелены лишь на 0,1% от этих возможностей. А все вместе взятые технологические компании охватывают лишь около 1%. Это означает что 99% это возможности которые упускаются. Инвесторы всегда беспокоятся: «Ах, вы ребята собираетесь потратить слишком много денег на эти сумасшедшие вещи.» Но это как раз сейчас те самые захватывающие вещи — YouTube, Chrome, Android. Если вы не делаете что-то сумасшедшее значит то что вы делаете неправильно!
Tim: Но с другой стороны — первопроходцам всегда приходится не легко. Посмотрите что было с Xerox PARK, не похоже чтобы их фантастические инновации особо помогли самой корпорации.
Larry Page: PARC имела впечатляющую исследовательскую организацию и они внесли большой вклад в современные вычислительные технологии. Но они не были сосредоточены на получении прибыли от своих изобретений. А этого упускать нельзя. Возьмём к примеру компанию Tesla, которой я восхищаюсь. Они не просто сделали действительно инновационный автомобиль, а вероятно около 99% своих усилий потратили выясняя как сделать чтобы их продукт стал массовым и популярным и чтобы им действительно начали пользоваться. Когда я еще только рос, я хотел быть изобретателем. Но потом я понял что есть слишком много печальных историй о изобретателях, таких как Никола Тесла к примеру. Это удивительные люди, которые не имели большого влияния, по причине того что не превращали свои изобретения в бизнес.

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

Введение

Из всех наслаждений, отпущенных человеку в жизни,
самое изысканное — шевелить мозгами.
(Борис Акунин)

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

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

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

Прежде чем мы написали этот материал, наши приложения загрузили более 2 000 000 раз, мы провели порядка 50 больших промо кампаний, побывали в топах AppStore более, чем в 24-х странах пока наконец не собрали всё это в один большой work flow. В статье почти нет очевидных вещей про ключевые слова, красоту иконок, скриншотов и рекламные кампании. Мы попытались привести работу продуктовой компании к единой модели, ответив на вопросы: «что?», «когда?», «зачем?» и даже на вопрос «а дальше что?». Если вы разрабатываете собственное приложение, хотите начать это делать или у вас просто есть друг разработчик или маркетолог продуктовой компании — в этой статье вы найдёте много полезной информации.

Довольно часто, выступая на различных конференциях, мы делились желанием выпустить под открытой лицензией KittenPHP, согласно традиции, заложенной крупными IT-компаниями, такими как Google и Facebook.

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

В связи с этим под катом вас ждет более подробный рассказ о внутреннем устройстве ВКонтакте и тех инструментах, которые сегодня стали доступны opensource-сообществу.

habrahabr.ru/post/179397 Вторая часть уже здесь!

Что такое мнемоника?

Я не люблю писать определения из википедии, поэтому объясню своими словами, что такое мнемоника. Мнемоника — это способы запомнить информацию путем смены типа информации. Вместо запоминания цифр запоминаете слова. Вместо слов можно запоминать места. Вместо ходов в шахматах — стихотворение.

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

Чтобы нам не ошибаться,
Надо правильно прочесть:
Три, четырнадцать, пятнадцать,
Девяносто два и шесть.
Ну и дальше надо знать,
Если мы вас спросим —
Это будет пять, три, пять,
Восемь, девять, семь.

пишите в комментариях другие примеры стишков для числа Пи. Я знаю, что их очень много

Скажу откровенно, я специально не искал на хабре информацию по мнемонике. Я хочу изложить взгляд со своей стороны: то, что знаю я. У меня не было желания “разбавлять” информацию другими источниками. Под катом много полезной информации, которую я очень долго собирал по крупицам.

Эпоха путешествий во времени еще не наступила, а человечество уже давно пытается разрешить сопутствующие им парадоксы. Мы поговорим о самом очевидном из них: что же все-таки произойдет при вмешательстве в ход истории? Существует несколько вариантов того, как поток времени реагирует на действия путешественника из будущего. Эти модели можно увидеть в фантастических фильмах, о них все больше начинают говорить ученые, но какая модель ближе к истине — единого мнения пока нет. Мы только начинаем проникать в тайны времени, и еще не обладаем возможностью экспериментировать с перемещениями в прошлое. Что же можно прояснить в данном вопросе уже сейчас? Под катом нас ждет экскурсия по основам механики времени, мы порассуждаем о парадоксах, и проведем небольшой эксперимент. Да, это будет испытание виртуальной машины времени, построенной на основе алгоритма «Жизнь»!

В середине прошлого лета на программерскую рассылку отдела клиентских игр Mail.Ru Group пришло письмо – «Объявлен конкурс на позицию преподавателя курса Java в нашем совместном проекте с МГТУ им. Н. Э. Баумана». Как программист и сотрудник отдела я это письмо тоже получил. Как выпускник физтеха, а в прошлом преподаватель и научный работник, решил откликнуться.
Так для меня началась история работы преподавателем в Технопарке. Собственно об этом (о работе, о Технопарке, о своем курсе и о студентах) я и хочу вам рассказать.

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

самая суть

С появлением доступных ARM и MIPS решений, на которые можно установить Linux или WinCE, любительский эмбеддинг вышел на качественно новый уровень(вообще он там давно был, но не в таких широких масштабах как сегодня). Появление таких массовых программных продуктов как Android, очень сильно популяризировало процессоры с не х86 архитектурой, открыло широкой общественности новые возможности в виде снижения цены на быстродействующее железо и обеспечило доступ к той информации, которая раньше распространялась исключительно после подписания NDA.
И всем вроде бы хороши .nix железяки: роутеры, Raspberry Pi и разные девайсы а-ля МК802. У многих они рулят производственными и домашними процессами, роботами и кофеварками. Но, низкая скорость реакции на внешнее воздействие, несколько ограничивает применение таких систем в эмбеддинге. Такими функциями, которые напрочь отсутствуют в подобного рода устройствах(имеется в виду ширпотреб, а не специализированные решения раз, два), могут быть ШИМ с аварийным отключением, скоростной PID регулятор, обработка квадратурного энкодера и многие-многие другие. Все эти вещи требуют известной степени реалтайма.

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

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

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

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

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

Более полугода назад в поисках что посмотреть, я листал топ произведений. Это занятие повторялось уже много раз и успело надоесть — постоянно приходилось пропускать то, что я смотреть не хочу. Имхонетами раньше не пользовался, да и не доверял им из-за специфики искомых произведений. На сайте, где я производил поиски, была возможность создать свой список просмотренных произведений и выставить оценку, также были доступны оценки других пользователей. Тут мне в голову пришла гениальная идея, как оказалось позднее банальная, — используя оценки других пользователей делать рекомендации. Данная деятельность называется коллаборативной фильтрацией, а программа её реализующая — Рекомендательной системой(РС). Оглядываясь назад я понимаю, что совершил множество ошибок из-за недостатка информации и её труднодоступности в данной тематике, а что самое главное — сильно переоценил РС. В данном посте я сделаю обзор основных типов и алгоритмов РС, а также постараюсь передать часть своих знаний и опыта.

Вступление

В этой статье я попробую рассмотреть безопасность чуть-чуть повыше ядра, а именно: как работает безопасность в Native user space. Мы коснемся темы процесса загрузки операционной системы и рассмотрим структуру файловой системы Android. Как я уже говорил, я не очень силен в Linux, поэтому если заметите неточности, то исправляйте — меня научите и статью улучшите. Так как эта тема довольно обширная, я решил разбить её на две части. В первой части мы рассмотрим процесс загрузки операционной системы и особенности файловой системы. Всем кому интересно, добро пожаловать!

Добрый день.

Мне 25, я закончила Факультет Прикладной Математики в Минске, сейчас живу в Америке (Калифорния). В 2010 моя двоюродная сестра при мне готовила документы на бакалавриат (она поступила в Stanford на Management, Science & Engineering), и в этом году я сама уже подавала документы на мастер программу (поступила в Carnegie Mellon на MS in Software Engineering). После длительной подготовки и километров потраченных нервов, загадочная система поступления стала мне чуть более понятна. Спешу поделиться некоторыми моментами, которые были для меня в новость.

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

Примечание переводчика.

Есть интересная технология в мире БД — MUMPS. Этот язык программирования и доступа к данным известен уже несколько десятилетий, отлажен и является взрослой проверенной технологией.

Приведу аналогию: если SQL можно сравнить с Бейсиком, то MUMPS больше похож на Си — даёт высочайшую производительность, гибкость и универсальность, позволяя создавать наисложнейшие структуры данных.

Перед вами перевод первой части статьи «Extreme Database programming with MUMPS Globals». Если сообществу он покажется интересным, то последует перевод второй части.

Есть одна бородатая шутка: «если у вас есть проблема, и вы собираетесь решать ее с использованием регулярных выражений, то у вас есть две проблемы». Действительно, регулярные выражения – очень мощный и гибкий инструмент, применяемый для решения весьма широкого круга задач. Но, как водится, для поддержания баланса, такой серьёзный инструмент имеет весьма недружелюбный вид.

(<([a-z]+[^>]*)>)(.*)(</\2>)

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



Когда-то и мне пришлось по долгу службы подружиться с регулярными выражениями. Прочитав Фридла и несколько статей на Хабре, я, конечно, начал понимать этот синтетический язык. Тем не менее, каждый раз, когда приходилось написать очередную регулярку, я быстро закапывался в нагромождении скобок, слешей, точек, плюсов, знаков вопроса, и других хорошо вам знакомых конструкциях. Разобраться в этой каше было очень сложно, особенно если возвращаешься к задаче месячной давности. Я мечтал об инструменте, который помог бы мне разобраться в собственном творении. Приблизительно подходящих по смыслу сервисов нагуглилось с десяток, но все они приносили мало пользы. Как раз тогда я и начал разрабатывать этот проект.

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