День добрый,

Наткнулся на весьма интересный сайт http://www.cookingknife.ru/ посвящённый кухонным ножам.
Помимо прочего, сайт содержит много контента для не специалистов, сделанного при этом весьма качественно (хорошие статьи, иллюстрации и видео!) и не содержит рекламы.
Отдельная фишка — в системном подходе авторов, без навязывания единственно правильной точки зрения.
Рекомендую.

В качестве примеров:
Подборка видео "Техника владения" http://www.cookingknife.ru/pages/Tehnika.shtml
Статья "Анатомия ножа" http://www.cookingknife.ru/pages/Anatomy.shtml
Вводное видео "Вы решили купить нож..." http://www.cookingknife.ru/player.aspx?vid=53364092

Один весьма известный и уважаемый в узких кругах исследователь взял на себя труд глянуть по диагонали отдельные части реализации иксов и подготовить об этом презенташку для очередной конференции по новым компьютерным технологиям и защите компьютерных программ: http://media.ccc.de/browse/congress/2013/30C3_-_5499_-_en_-_saal_1_-_201312291830_-_x_security_-_ilja_van_sprundel.html

Для тех, кому лень смотреть и делать выводы... Пара цитат из презентации:

"GLX is a horrible demotivator! 80,000 lines of sheer terror."

и

"In the past
couple of months I've found 120 bugs there, and I'm not close to done."

речь о 120 security багах, если кто не понял. После такой внезапности, xorg-разрабы решили (видимо впервые за все время существования проекта) просканить свой код хоть каким-нибудь статанализатором. Им под руку попался http://cppcheck.sourceforge.net/...

Наш доклад с PoC 2013 об анализе защищенности кода и автоматической генерации эксплоитов: слайды http://www.powerofcommunity.net/poc2013/slide/sergey.pdf, демка http://buff.ly/1hO6rAX

На данный момент я кажется окончательно вывел для себя правила по выбору языка для той или иной задачи. До этого многие годы писал на C++, C, Python, Java и Objective-C. Перепробовал кучу экзотических языков, таких как OCaml, Erlang, Scala, Lisp, Closure. Так как я не занимаюсь разработкой UI, Web-сайтов или мобильных приложений, все мои соображения актуальны исключительно для разработки системных приложений, сетевых приложений и бизнес логики. Кроме того, все что я пишу в этой заметке относится к командной разработке приложений в рамках относительно крупной компании, и будет не актуально для команд из 1-2 разработчиков или “домашних” проектов.

http://sysdev.me/how-to-select-programming-language/

С тех пор как Nokia свернула работы по развитию Symbian, я никак не могу определиться, какими же телефонами мне пользоваться. Выбор-то, по большому счету, не велик: либо красивый iPhone с ограниченным функционалом и выбором железа, но более-менее адекватной фильтрацией приложений в AppStore и какой-ни какой защитой личных данных, либо страшненький Android с широким набором функционала, выбором железа, но совершенно никакой защитой персональны данных, ведь 9 из 10 “фонариков” хотят читать твои СМС-ки и получать полный доступ к сети. Если же говорить об идеальном с точки зрения железа телефоне, то на данный момент это Nokia Lumia 1020, но идеальное железо – это еще не причина терпеть Венду и ограниченный набор приложений на телефоне.

http://sysdev.me/samsung-galaxy-note-3/

Довольно часто возникает необходимость разобрать новый большой проект и не совсем очевидно с какой стороны подступиться к огромной горе исходных кодов которая свалилась на вас. Если вам повезло и проект написан на C++, C, Objective-C, Python, Java, PHP, C#, Фортран или VHDL то простое решение есть – Doxygen + GraphWiz.

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

http://sysdev.me/learning-new-project/

Думаю, ни для кого не секрет то, что основная реализация языка программирования Python фактически не поддерживает многопоточности. Есть модули которые позволяют эмулировать потоки посредствам процессов, но подобный путь крайне требователен к ресурсам и поэтому его применимость крайне ограниченна, особенно для большого количества операций ввода/вывода. При этом, в подавляющем большинстве случаев, распараллеливание задач не несет какого-то серьезного практического смысла и просто является одним из возможных архитектурных решений. В качестве альтернативы потокам могут выступать асинхронные операции, а с учетом ограничений интерпретатора, подобный подход должен бы был быть родным подходом в Python уже много лет как. Тем не менее, появился долгожданный модуль asyncio только в Python 3.4, но это в любом случае лучше чем никогда.
http://sysdev.me/python-asyncio/