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

Очень интересная статья появилась сегодня на wired.com. Буквально за один час у автора статьи Мэта Хонана были взломаны Amazon, GMail, Apple и Twitter аккаунты и была удаленно уничтожена информация на его iPad, iPhone и MacBook. Среди прочего он потерял все фотографии своей дочки с ее рождения, многие документы и большую часть переписки. Очень интересно в этой истории то, как злоумышленник получил доступ к Amazon аккаунту и AppleID — для этого не понадобилась ничего, кроме доступной в сети информации и телефона.

Вступление

Всякому известно, что Win32 API не отличается чрезмерным удобством. Например, для вызова функции частенько приходится заполнять большую структуру с полями вроде cbSize, dwFlags и т. д. Или для получения строки сначала узнавать размер ее, готовить буфер и затем лишь получать саму строку. Далее пойдет речь про функцию ::HttpQueryInfo() и применение идиомы «traits» для упрощения работы с ней.

В начале 20 века Гарингтон Эмерсон сформулировал 12 принципов производительности и организации труда, которые можно применить буквально в любой области и позволяют достичь максимальных результатов человеческой деятельности и предприятия в целом. После прочтения его книги я осознал, что до большинства его принципов я дошел своей головой путем ошибок в своей жизни, кажется если бы я прочитал его книгу раньше моя жизнь была бы более продуктивной. В этой заметке я рассмотрю эти принципы для фрилансерской деятельности.

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

Капитан Очевидность намекает: чтобы такого не допустить, важно уметь понимать, в каком состоянии находится ваш продукт на каждом этапе его развития. В этой большой статье предлагается методика оценки его состояния в самой наглядной форме – в форме таблиц и графиков. Здесь обобщен мой опыт и опыт всей команды новосибирского офиса Parallels за последние шесть лет. Чтобы было понятно: мы делаем Parallels Plesk Panel – хостинг-панель, которая используется примерно на каждом втором сервере в мире, предоставляющем услуги веб-хостинга. Применив эту методику, мы получили вот такие результаты:

1. существенно улучшилось качество выпускаемых релизов (согласно Incident rate);
2. релизы стали более предсказуемыми, точность наших прогнозов и оценок выросла в разы;
3. появилось понимание, почему что-то идёт не так и как этого избежать в будущем.

Заинтересованных лиц прошу под кат и в комменты. Отвечу на любые вопросы.

Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

Теперь меня регулярно просят рассказать про Git и что в нем такого. Уже надоело, поэтому этот пост для тех, кто еще сомневается.

Автор: Джоэль Спольски. Оригинал.

Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.

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

Последнее время я слышу множество разговоров о разработке, основанной на тестировании (TDD), о разработке, основанной на функционировании (BDD), об экстремальном программировании (XP), о SCRUM-е, о собраниях стоя и ещё Бог знает о каком количестве методик для создания ПО, но все эти методики не имеют смысла, если ПО, которое мы создаём не соответствует требованиям пользователей. Давайте я попробую это объяснить по-другому. Идеальная реализация неправильно составленной спецификации бесполезна. Так же, как и полезность прекрасно написанной библиотеки стремится к нулю, если у неё нет документации. Что-то определённо не так, если ваше приложение не решает поставленную проблему или, если никто не знает как им воспользоваться.

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

Первым делом создайте Readme файл.

Файлы здесь.

Автор: Эндже Альбертини (Ange Albertini)
Перевод на русский: Lyr1k

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

Метод не предназначен для массового повседневного использования — на подсознательное запоминание пароля требуется около 45 минут тренировки, кроме того, он не даёт особых преимуществ в случае удалённого доступа — злоумышленники всегда могут силой или угрозами заставить пользователя войти в систему. Основное его назначение — физический контроль доступа в закрытые зоны и помещения, например секретные лаборатории или банковские хранилища.

Доброго времени суток, хабролюди!

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

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

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

Есть и другая крайность, когда команда можем потратить недели в поисках идеального решения (Святого Грааля архитектора), когда дизайн будет способен «расширяться» во всех возможных направлениях, и быть настолько «гибким», что реализовать его не будет никакой возможности.

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

Итак, вуаля!


За источник информации была взята статья из вики. В блок-схеме «UTF-16 → CP 866» означает, что исходная кодировка была «UTF-16», а распозналась она как «CP 866».

Как всегда — кликабельно. Исходник в .docx: здесь.

Вот, задался таким вопросом… С помощью гугл транслейта и такой-то матери, родилась такая блок-схемка:



картинка кликабельна

Кому нужен сорец (в .docx): тут

Многие из нас пользуются отладчиком Visual Studio 2010, однако, я могу поспорить, что большинство не в курсе, что у него есть дополнительные недокументированные настройки облегчающие процесс отладки.

В этой статье я расскажу, как избавиться от постоянного попадания внутрь библиотечного кода при пошаговом Step-In выполнении. Это для затравки. Позже я опишу механизм управления представлением типов в отладочных окнах типа locals и watch (все видели, как красиво там отображаются вектора/карты и т.п.?).

Пожалуйста учтите, что основной упор будет сделан на отладку Native кода.

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

Паттерн Singleton появился, пожалуй, как только появились статичные объекты. В Smalltalk-80 так был сделан ChangeSet, а чуть в самых разных библиотеках стали появляться сессии, статусы и тому подобные объекты, которых объединяло одно — они должны были быть одни-единственные на всю программу.

В 1994 году вышла известная книга «Паттерны проектирования», представив публике, среди 22-х прочих, и нашего героя, которого теперь назвали Singleton. Была там и его реализация на C++, вот такая:

Эксклюзивно для Хабра.



(кликабельно)

Приветствую тебя, хабрачитатель!

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