Введение

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

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

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

Такое решение верное, и задача прошла все назначенные ей тесты. Однако мой преподаватель сказал, что задачу можно решить намного красивее. Так я и познакомился с замечательной конструкцией: деревом Штерна — Броко.

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

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

Если когда-нибудь вы задумывались над тем, что значат слова «the processor supports precise aborts» в даташите, прошу под кат.

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

Один из наиболее универсальных советов, которые мы даем в Y Combinator, это браться за сложную работу. Многие начинающие основатели верят, что стартапы или «взлетают» или нет. Вы создаете что-то, делаете это доступным, и, если вы придумали самую лучшую мышеловку, люди, как и было обещано, сами придут к вам. Или не придут, в таком случае у вас нет рынка. [1]

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

Привлечение клиентов

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

Сегодня вас ждет рассказ об исходном коде Doom 3 и о том, насколько он красив.
Да, красив. Позвольте мне объясниться.

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


^{автор фото: Андрей Бутко, по лицензии Creative Commons Attribution-Share Alike 3.0 Unported}

Об этом пишут Кристиан Энгстрем и Рик Фальквинге в брошюре, отрывок из которой (о цензуре) я уже переводил ранее. В отрывке, который я публикую сегодня, они анализируют копирайт в части наказаний за его нарушение.

^{Бизнес-ангел часто смотрит на стартаперов с недоумением}

Предположим, вы придумали какое-то железо, и теперь хотите начать его производство. У вас уже есть прототип: вот он, в руке, коряво выглядит, в 4 раза больше нормального размера и из него торчит провод. Но он работает. У вас горят глаза: ведь осталось только «допилить» его и начать производить по всему миру. Из маркетингового плана у вас есть только «запостить про железку на Хабр – и всё закрутится».

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

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

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

Если интересны подробности: электрика/Интернет/отопление/водоснабжение с нуля — прошу под кат (сори, много фоток).

Дзэн Питона

Изучение культуры, которая окружает язык, приближает вас на шаг к лучшим программистам. Если вы всё еще не прочли «Zen of Python», то откройте интерпретатор Python и введите import this. Для каждого элемента в списке вы найдете пример здесь

Однажды моё внимание привлекло:

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

Как известно, функциональный подход к программированию имеет свою специфику: в нём мы преобразовываем данные, а не меняем их. Но это накладывает свои ограничения, например при создании программ активно взаимодействующих с пользователем. В императивном языке намного проще реализовать такое поведение, ведь мы можем реагировать на какие либо события «в реальном времени», в то время как в чистых функциональных языках нам придётся откладывать общение с системой до самого конца. Однако относительно недавно стала развиваться новая парадигма программирования, решающая эту проблему. И имя ей — Functional Reactive Programming (FRP). В этой статье я попытаюсь показать основы FRP на примере написания змейки на Haskell с использованием библиотеки reactive-banana.

В какой-то момент я стал замечать, что пишу более качественный: оптимальный, логичный и читаемый код, но пишу его медленно. По крайней мере, куда медленнее, чем лет 15 назад. Да, на старый код без слёз не взглянешь: всё можно сделать оптимальнее и, по крайней мере, читабельнее. Но код был написан быстро.

Проблема в контроле. Я стал жестче и глубже контролировать код и… стал тратить на этот контроль слишком много ресурсов.

Основной принцип прост. Если контролю подлежит 10-20% случаев, то на контроль надо тратить… 0% ресурсов. Баги и переписывания всё равно будут. Но лучше разделить кодирование и отладку и на время кодирования об ошибках вообще забыть.

Долгое время занимаясь разработкой под Android, я постепенно пришел к выводу, что многих вещей мне, как разработчику, сильно не хватает. Тогда, в начале 2010-го, не хватало только C++ exceptions и RTTI. Без них любой нетривиальный C++ код просто не мог быть портирован на Android и требовал практически полного переписывания. Это было очень существенное ограничение, которое никак не давало мне покоя. К счастью, Android — это open source, поэтому, вооружившись максимой «если тебе что-то нужно, сделай это сам», я засел за работу. К моему удивлению, сделать поддержку полноценного C++ с исключениями и RTTI оказалось довольно несложно. Потребовалось всего около недели работы. Далее был сделан сайт, на который и были выложены получившиеся пакеты для Windows, Linux и Mac OS X, а также патч и инструкция по сборке.

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

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

Иллюстраций: 34, символов: 51 609.

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

После того как глава Nokia заявил, что дни Symbian сочтены, я решил изучить платформу Android.

Для лучшего усвоения материала я решил написать полезную, хотя бы для себя, программку. Но написать ее не по детски, когда куски примитивного кода копируются из документации, а по взрослому с разработкой архитектуры, и использованием современных технологий программирования TDD, MVP и IoС.

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



Под катом одно из возможных решений.

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

В предыдущей статье я провёл некий ликбез по внутренностям Flex-компилятора (по части MXML) и рассказывал, как избавить себя от проблем работы с классами в MXML, требующими параметры конструктора. Сейчас мы разберём другую сторону вопроса — установка параметров в custom-значения (к примеру, константы) без использования механизма Binding (хотя, очень похоже на него).

Последние несколько месяцев я работал над SDK для Android, входящим в платформу управления контентом Nuxeo. Особенно много работы было в последнее время, с приближением официального релиза SDK. Я хочу поделиться несколькими практическими советами по поводу разработки под Android, в частности тестирования и эмуляции. Уже после нескольких дней разработки я понял, что работа с эмулятором Android — не сахар, потому что он чудовищно медленный.

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

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

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

By Mike Vanier

В предыдущих статьях этой серии мы изучали концептуальный базис монад, но обсуждение наше было слишком абстрактным. Теперь, когда вы, я надеюсь, поняли, что монады такое и для чего они нужны, пришло время для детального рассмотрения специфических монад. Это значит, что мы определим корректные воплощения класса типов Monad для множества различных понятий вычислений, которые мы увидели раньше. Мы используем наши знания, чтобы получить монадическую композицию в каждом конкретном случае через монадическое применение (оператор >>=), и с помощью монадных законов мы выведем определение return.

26 Апреля 2007 года. Adobe делает заявление, что Flex Framework переводят на open source. Данная новость вызвала бурю оваций среди флешеров всего мира, что появятся принципиально новые фреймворки на его основе, но дальше пары-тройки проектов это не пошло.

В то время я делал проекты с использованием Flex-а, и чем больше проекты становились, тем сильнее мне не нравилось некоторые нюансы его внутреннего устройства.
Думаю, каждому, кто работал с Flex-ом, известны его проблемы, а так же низкое качество кода как уже написанного, так и генерируемого из MXML, поэтому я решил вмешаться в этот процесс с целью навести порядок и разобраться в устройстве Flex компилятора, и начал с добавления «сахара» в MXML, стараясь сделать это как можно сильнее в духе остальных фич детища Adobe-а. Спустя два года, я принял решение поделиться своими знаниями с Вами.