09.01.2014
kochetkov.vladimir
Один весьма известный и уважаемый в узких кругах исследователь взял на себя труд глянуть по диагонали отдельные части реализации иксов и подготовить об этом презенташку для очередной конференции по новым компьютерным технологиям и защите компьютерных программ: 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/...
13.01.2014
kochetkov.vladimir
Наш доклад с PoC 2013 об анализе защищенности кода и автоматической генерации эксплоитов: слайды http://www.powerofcommunity.net/poc2013/slide/sergey.pdf, демка http://buff.ly/1hO6rAX
03.04.2014
velkin
О пакетах нужно знать то, что они соответствуют пространствам имён (namespace). Соответственно на них действуют те же самые правила. По большому счёту это логическая группировка типов. Под типами могут пониматься как классы (class) – типы определяемы пользователем, то есть программистом, так и другие, например структуры (struct), объединения (union), перечисления (enum), псевдонимы (typedef).

Здесь и далее анализ пространств имён рассматривается с точки зрения C++. Истинным Java программистам подобные основы вряд ли нужны, у них скорее будет передозировка проектированием, чем его недостаток. А вот C++ исповедует множественные парадигмы программирования, из-за этого часто его пользователи охватывают лишь одну из них и начинают хаить язык сверху донизу, якобы у них память утекает и тому подобное.

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

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

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


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

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

Для этих целей существует множество способов, но речь сегодня пойдёт лишь об одном из них. Технология электронных чернил (e-ink) получила широкое развитие благодаря имитации бумаги. Полный угол обзора и отражённый рассеянный свет увеличивают комфортность чтения, а так же снижают нагрузку на глаза. В свою очередь это уменьшает сенсорную перегрузку, что позволяет получать больше информации и работать гораздо продуктивнее.

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

http://sysdev.me/samsung-galaxy-note-3/
20.02.2014
kaa.python
Довольно часто возникает необходимость разобрать новый большой проект и не совсем очевидно с какой стороны подступиться к огромной горе исходных кодов которая свалилась на вас. Если вам повезло и проект написан на C++, C, Objective-C, Python, Java, PHP, C#, Фортран или VHDL то простое решение есть – Doxygen + GraphWiz.

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

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

А>Мне кажется второй способ более простой и удобнее для чтения отладки и т.п.

А>Есть ли какая-то эффективность у 1го способа или это уже можно считать как устаревший подход ?

На нынешнем этапе развития науки и техники устаревшим считается скорее второй подход.

Во всех трех вариантах:

1) Begin/End-методы,
2) обертка Task.FromAsync над ними, упомянутая TK
и
3) синхронные сетевые вызовы в теле таски,

непосредственно вызовы и ожидания ответов действительно происходят в потоках из IO-пула. Но вариант №3 потребляет _еще_один_ поток, в дополнение к уже потребляемым IO-потокам. Т.е. в общем случае требует в два раза больше потоков (=> в два раза больше памяти) и рано или поздно упрется в лимит на их число.

Преимущества первых двух вариантов над третьим особенно хорошо видны, если принудительно ограничить размер ThreadPool-а:

[c#]
class Program
{
const int CallCount = 30;
<  1  …  26  27  28  29  30  31  32  …  47  > rss