Всем здравствуйте, меня зовут Олег, мне 17 лет, и сегодня я расскажу вам о процессе поступления в MIT.
Дабы сохранить цельность повествования, следует отметить, что статья написана 15 марта 2013 года, в день оглашения вердиктов о зачислении студентов.

Картинка для привлечения внимания

Когда я поступал в Массачусетский технологический институт, я с удивлением обнаружил, что в рунете нет не то что мало-мальски съедобной «истории успеха», связанной с поступлением в MIT, а вообще хоть какого-то руководства по поступлению в топовые американские университеты своими силами. Особенно на бакалавриат. Я подумал: «Что ж, видимо, придется написать мне». Я постараюсь донести информацию в наиболее понятном виде.

Несколько дней назад на xkcd.com был опубликован комикс о неэффективных методах сортировки. Alt-текст к нему рассказывал о сортировке методом StackSort, который заключается в том, чтобы скачать со StackOverflow блоки кода, которые можно найти по запросу «сортировать список» и запускать один за другим, пока не найдётся работоспособный вариант. Бред? Ещё бы не бред! Встречайте на Гитхабе реализацию StackSort на JavaScript.

«Что? Стивен Кинг „Как писать программный код“ ?! Нет такой книги! Да он вообще не программист ни разу!».
Да, так и есть. Тем не менее — книга с таким содержанием у него есть. Хотя он и не думал, что пишет её об этом. Хотя в результате написал. Хотя, наверное, и не знает об этом. О чём же я тут рассуждаю? О недавно прочитанной мною прекрасной книге «Как писать книги» (англ. — «On Writing»).

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

Article translated from Oliver Emberton blog abetterlife.quora.com
Перевод статьи abetterlife.quora.com/How-to-master-your-time-1

Секрет тайм менеджмента прост: приемы джедая

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



Можете думать о Татьяне как о воплощении Вашей мечты, Вашего вдохновения – пусть это самое важное в Вашей жизни.

О чем эта статья

Сегодня я расскажу про библиотеку Boost Signals — про сигналы, слоты, соединения, и как их использовать.

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

DISCLAIMER: Все изложенные ниже приемы работают для меня, и не факт, что будут работать для вас. IMHO only, на истинность в последней инстанции не претендую.

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

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

Отдых тела и ума

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

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

Активное тело, температура в помещении
Иногда нужно размять тело. Вовсе не так просто в СССР была производственная зарядка, о которой так бодро пел Высоцкий.

Тут есть глубокий физический смысл. Когда вы приводите свои мышцы в активность, повышается их тонус, в теле изменяется обмен веществ. Организм понимает, что нужно стать бодрее — и через 10-15 минут разминки вы себя не узнаете.

Сегодня я хочу рассказать вам о выходе второго stable-релиза IM-мессенджера Miranda NG, форка Miranda IM, созданного бывшими разработчиками ядра и ряда плагинов.



Стабильные сборки: http://www.miranda-ng.org/distr/stable/

Исходный код
Ресурс со всеми портированными плагинами
Трекер

Статья-прародитель, содержащая небольшой FAQ для «введения в курс дела»


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

История, отличия и другая информация под катом.

Это перевод статьи Being a Remote Worker Sucks — Long Live the Remote Worker Скотта Хенселмана за 27 февраля.

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

Работать удалённо – прекрасно, отстой.

Какое-то время назад ко мне в Skype и «Мой круг» постучалось несколько человек с одним и тем же вопросом: «Как и где можно защитить диссертацию по QA?». Вопросы удивили. Давно не слышал о том, что кто-то хочет писать научные труды, особенно по QA. Вместе с тем, в последнее время я начал замечать, что ко мне все чаще стали приходить на собеседования люди, которые или уже пишут научную работу, или планируют заняться научной деятельностью.

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

• «Тестирование на основе формальных спецификаций в процессах разработки программных комплексов» (Петренко Александр Константинович, д.ф.-м.н),
• «Методы и программные средства управления конфигурациями проектов разработки встроенных систем» (Налютин Никита Юрьевич, к.т.н.),
• «Методы реализации регрессионного тестирования по расширенным тестовым наборам» (Епифанов Николай Анатольевич, к.т.н),
• «Разработка метода построения комплекса нагрузочного тестирования распределенной информационной системы» (Ермыкин Алексей Александрович, к.т.н).

Однако все это были уже готовые и законченные работы, так сказать, финал. Мне же была интересна «предыстория». Личный успешный опыт защиты диссертации (правда, по экспериментальной физике) на тот момент позволял видеть лишь общую картину, без какой-либо конкретики. Поэтому я собрал некоторую информацию, добавил мысли из личного опыта и решил поделиться всем этим.

Вступление

Как справедливо заметил Fred Brooks, серебряной пули, способной поразить зверя разработки программного обеспечения, не существует. Пока возникают новые требования, идеи и находятся новые баги, программы живут и изменяются. Путь, который проходит код от версии к версии, может быть крайне сложен и извилист. К его созданию причастно много людей: разработчики, тестировщики, бизнес-аналитики, заказчики и т.п. Несмотря на то, что существует много разных видов разработки – аутсорсинг, продуктовая разработка, open-source и т.п., проблемы, стоящие перед командой, остаются примерно одинаковыми. Программное обеспечение – вещь сложная, потребитель хочет получить его как можно быстрее (и дешевле). Качество при этом должно быть приемлемым. Перед командой разработки стоит серьезная задача – наладить эффективное взаимодействие. Одним из самых главных средств коллаборации внутри команды разработчиков является сам код, который они пишут.

Вчера выдалась свободная минутка и я присел почитать Хабру. Одна из первых статей на которую наткнулся “Наш ответ 3doodler`у. Собран за 20 минут”. И вот читаю я её, видео смотрю, и чувствую что у меня дежавю. Причём такое нехорошее. Поднимающее волну возмущения. Мне некомфортно.

Здравствуйте! Прочитав недавно статью про оконные менеджеры в Linux, мне захотелось рассказать всем о менеджере, который был там упомянут — «awesome».
Это тайлинговый windows manager для unix (linux, freebsd, openbsd, netbsd).

Все мы знаем как хорошо и похвально принимать участие в разработке открытых проектов.
К тому же потом можно мерятся количеством коммитов в rails и зарплату попросить побольше.

А что если вы решили написать свой open source проект?

Приветствую! Надеюсь, эта статья будет кому-нибудь полезна.

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

Итак, кончаю муть, перехожу к «технической» и практической стороне дела.

pdb – Интерактивный отладчик

Версии Python: 1.4 и выше

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

Кроссворд, подсказки в котором — регулярные выражения.

Оригинал в PDF.

Автор — не я! Это часть MIT Mistery Hunt 2013.

Большинство людей не умеют писать unit-тесты. И даже те, кто применяет модульные тесты в ежедневной разработке, зачастую признают, что получившиеся тесты иногда не очень эффективны по определенным причинам. К этой категории людей я могу отнести и себя. В первую очередь, такой «причиной» является некоторая появляющаяся «инертность» кода, заключающаяся в том, что если требуется немного изменить какой-то ключевой алгоритм, добавить пару строчек кода, то при этом «падают» ~100 модульных тестов и приходится тратить продолжительное время на то чтобы заставить их работать вновь. Итак, приступим к «хорошим рекомендациям» при написании автоматических модульных тестов. Нет, я не буду капитаном очевидностью, в очередной раз описывая популярный стиль написания тестов под названием AAA (Arange-Act-Assert). Зато попытаюсь объяснить, чем отличается Mock от Stub-а и что далеко не все тестовые объекты — «моки».

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

Итак, что мы представляем из себя на данный момент? В Stack Exchange сейчас работают 75 человек, примерно половина занимается продажами (маркетинг и реклама), остальные же — созданием продуктов (разработка, дизайн, управление сообществами). БОльшая часть удалённо работающих сотрудников занимаются разработкой: 16 удалённых и 18 офисных разработчиков, сисадминов, дизайнеров. У нас команда-гибрид, которая, как мне кажется, лучшая в мире. Я руковожу отделом проектирования, так что буду говорить в основном о разработчиках, но это применимо ко всем должностям.

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

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

Вот, к примеру, что советует президент Microsoft в России для борьбы с нехваткой времени:

• Планируйте график таким образом, чтобы решать как можно меньше второстепенных срочных задач, а важные — решать до того, как они станут срочными;
• Занимайтесь любимым делом с максимальной вовлечённостью;
• Рассматривайте принцип жизненного баланса как важную личную и менеджерскую задачу.

Да, мы не можем поставить мир на паузу. Но мы можем изменить подход к делам и отношение к собственной жизни.