К слову сказать, на это понадобилось лет шесть изысканий.

Очевидно, что если вы что-то производите (или выполняете проекты, это не так принципиально), то очень-очень хочется делать это:
— быстро
— качественно
— точно в срок
— с минимальными затратами (инвестициями)
Это значит, что должно быть найдено какое-то решение, позволяющее делать именно так.

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

Свои изыскания в этой части мы начали году в 2006-м, полагая, что лучшее решение для производства — это MRP. В 2010-м году, после некоторых опытов по внедрению, мы поняли, что MRP не ведет к увеличению эффективности. Количество заказов, произведенных точно в срок, не увеличивается, запасы не уменьшаются, скорость производства не растет. А зачастую даже наоборот. Я написал статью об этом. Довольно эмоциональную. Видимо серьезно задев тех, кто зарабатывает на внедрении MRP. Но ведь целью внедрения любой системы менеджмента должно быть увеличение эффективности, не так ли? Многие об этом забывают, как, впрочем, и о том, что цель бизнеса – зарабатывать деньги. Поэтому внедрение MRP чаще всего превращается просто в проект по внедрению MRP, а в не в проект по улучшению эффективности производства.

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

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



То что вы делаете, называется интеграционным тестированием. Современные приложения достаточно сложны и содержат множество зависимостей. Интеграционное тестирование проверяет, что несколько компонентов системы работают вместе правильно.

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

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

Как избавиться наконец от насилия над собой в виде этих бесконечных техник? Делать то, что хочешь!
Если более развернуто, то обычно советуют работать на пересечении нескольких областей — делать:

1. то, что хочешь,
2. на что располагаешь талантом,
3. то, что служит на благо людей,
4. то, что приносит деньги.

Это просто идеальная самореализация!

Но как это сделать? Об этом обычно не говорят или неуверенно дают какие-то общие советы. Я долго копал и кое-какую методику все же нашел.

Данная статья написана под влиянием книги Дэвида Коупленда «Build Awesome Command-Line Application in Ruby» (купить, скачать и изучить дополнительные материалы). Большая её часть будет посвящена проектированию дизайна CLI-приложений вне зависимости от используемого языка. По ходу будут обсуждаться и вещи специфичные для ruby, но не страшно, если вы его не знаете, кода будет не слишком много. Можно считать эту статью довольно подробным обзором вышеупомянутой книги с вкраплениями собственного опыта. Книжку рекомендую!

Для начала я задам вопрос. Если посмотреть на сообщества IT-шников, можно заметить, что несмотря на обилие программ с красивым графическим интерфейсом, приложения командной строки остаются весьма популярны. Почему?
Ответов несколько. Во-первых, это красиво удобно — если вы можете описать задачу командой в командной строке, то её гораздо проще автоматизировать, чем если вам приходится анализировать передвижения мыши и клики на разные пункты меню. Во-вторых, это даёт возможность комбинировать программы невероятным числом способов, чего сложно добиться с помощью графических интерфейсов.
В значительной степени философия Unix базируется на том принципе, что множество маленьких утилит, каждая из которых умеет делать свою конкретную задачу — это лучше, чем одна многофункциональная программа-универсал. И это одна из причин успеха Unix-систем в мире IT-шников.
Наверное, каждый понимает, что обычного пользователя вряд ли удастся сманить от GUI к CLI, давайте сосредоточимся на нас, «компьютерщиках» и конкретизируем наши пожелания к CLI-приложениям.

Немного предисловия

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



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

Недавно наткнулся на ошибку в Android приложении Яндекс.Метро. Если бы был чемпионкой мира по синхронному плаванию, то обязательно спросил бы: «Кто создавал программу „для галочки“? Кто работал „на отшибись“? Кто слабое звено?». Недоумение вызывала не сама ошибка, а то, что она попала в приложение и всё ещё не исправлена.

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

Начать хотелось бы с главы «Изучение знаменитых (и не очень знаменитых) ошибок» из книги «Наука отладки». Если ещё не читали, то рекомендую прочитать. В этой главе описаны «глупые» ошибки и стечения обстоятельств, которые стоили жизней и миллионы долларов. Все эти ошибки объединяло то, что выявляющий их тестовый сценарий было чрезвычайно сложно воспроизвести, в результате многие проверки были просто пропущены.

В статье же мы будем рассматривать распространённые приложения, которые протестировать может любой участник команды. Давайте проведём небольшой эксперимент. Если у вас нет Android устройства, то попросите минут на десять у коллег или друзей. Скачайте приложение Яндекс.Метро и попробуйте его протестировать. Интересует актуальная на текущий момент версия 1.63 от 02.11.2012 сборка 159 (на Google Play стоит дата 21.01.2013). Для корректности проверки предлагаю снять галочку «Автообновление» в настройках Google Play.

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

Эта же ошибка может проявить себя не так явно:

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

В q&a разделе Хабра присутствует довольно много вопросов от людей, выбирающих open source проект, в котором они хотели бы поучаствовать: раз, два, три, четыре, пять.

Думаю, многие слышали про браузер Google Chrome и про то, что он основан на open source проекте Chromium. Так получилось, что в течении прошедшего года мне удалось внести небольшой вклад в этот проект в качестве независимого разработчика (то есть я не имею никакого отношения к Google и занимаюсь этим проектом в свободное от работы время). В процессе мне, естественно, пришлось разобраться с некоторыми техническими и организационными моментами, чем и хотелось бы поделиться.

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

13 июня 1944 года, через неделю после вторжения союзников в Нормандию, громкий жужжащий звук прогремел в небе избитого боями Лондона. Источником звука было недавно разработанное немецкое орудие войны: воздушная бомба V-1. Будучи предшественником крылатых ракет, V-1 была самоходной бомбой, управляемой с помощью гироскопов, питалась она от простого пульсирующего воздушно-реактивного двигателя, который поглощал воздух и воспламенял топливо 50 раз в секунду. Такая высокая частота пульсации давала бомбе характерный звук, зарабатывая ей прозвище «жужжащая бомба» (в оригинале – «buzz bomb» – прим. перев.).

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

Алгоритм Диффи — Хеллмана позволяет двум сторонам получить общий секретный ключ, используя незащищенный от прослушивания, но защищённый от подмены канал связи. Полученный ключ можно использовать для обмена сообщениями с помощью симметричного шифрования.

Предлагаю ознакомиться с принципом работы алгоритма Диффи – Хеллмана в замечательном видео от Art of the Problem в моем переводе.

Зачем нужно использовать два роутера

Не секрет, что Интернет в наше время становится доступен на все более космических скоростях. Старенький роутер на подобие моего Dir-300 уже не смог тянуть канал с новым 60 Мбитным тарифом, и встал вопрос покупки нового девайса, роль которого пришлась по плечу новенькому WNDR4000. Не буду утомлять дальнейшими подробностями и перейду сразу к самому интересному… Нет, не к тестам, которых уже и так немало, а к такому интересному вопросу, как настройка Wake on Lan на домашнем компьютерном парке.

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

А как же альтернативные прошивки, спросите вы? Да, тот же DD-WRT действительно решает проблему. Но в новых мощных роутерах альтернативная прошивка приводит к прямо-таки катострофическому падению производительности. Стоит ли ради возможности WOL терять преимущества хорошего, специально приобретенного роутера — вопрос грустный. Но как оказалось есть интересное решение.

Open Build Service – программное обеспечение с открытым исходным кодом, распространяющееся под лицензией GPL, которое заметно упрощает организацию собственных репозиториев для популярных дистрибутивов Linux и сборку бинарных пакетов.

Всё, что написано ниже, относится к Oracle Database и Oracle Exadata.

Преамбула

Полная луна освещала пыльную, петляющую дорогу, исчезающую среди холмов впереди. Я стоял в раздумье в начале своего пути, размышляя о том, куда может привести эта дорога. Отбросив сомнения прочь, я начал свой путь к виднеющейся вдалеке пирамиде, вершина которой терялась среди облаков. По дороге мне никто не встретился, кроме памятника, больше похожего на надгробие с изображением человека и надписью огромными буквами “In Codd we trust”. Подойдя к пирамиде на достаточно близкое расстояние, я сумел разглядеть, что она состоит из DB_BLOCK-ов, большей частью размером 8Kb, но можно было найти и больше. На каждом блоке был изображен логотип компании, которая использовала блок для хранения своих данных. Заметив небольшую толпу около входа в пирамиду, я заинтересовался, и решил узнать, что это такое. Подойдя совсем близко, толпа приобрела очертания – большой частью она состояла из студентов, но встречались и бизнес-аналитики, тестеры, программисты, можно было даже заметить пару менеджеров по продажам – все они рвались внутрь.

Мне очень нравится JavaScript и я считаю его мощным и удобным. Но для большинства начинающих JS-программистов, много проблем создаёт недопонимание аспектов языка. Часто конструкции языка ведут себя «нелогично». В данной статье я хочу привести примеры «граблей», на которые я наступил; объяснить поведение языка и дать пару советов.

Предисловие

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

Интерес к технологиям Big Data постоянно растет, а сам термин приобретает все большую популярность, многие люди хотят поговорить об этом, обсудить перспективы и возможности в этой области. Однако немногие конкретизируют — какие компании представлены на этом рынке, не описывают решения этих компаний, а также не рассказывают про методы, лежащие в основе решений Big Data. Область информационных технологий, относящихся к хранению и обработке данных, претерпела существенные изменения к настоящему моменту и представляет собой стремительно растущий рынок, а значит лакомый кусок для многих всемирно известных и небольших, только начинающих, компаний в этой сфере. У типичной крупной компании имеется несколько десятков оперативных баз данных, хранящих данные об оперативной деятельности компании (о сделках, запасах, остатках и т.п.), которые необходимы аналитикам для бизнес-анализа. Так как сложные, непредвиденные запросы могут привести к непредсказуемой нагрузке на оперативные базы данных, то запросы аналитиков к таким базам данных стараются ограничить. Кроме того, аналитикам необходимы исторические данные, а также данные из нескольких источников. Для того чтобы обеспечить аналитикам доступ к данным, компании создают и поддерживают так называемые хранилища данных, представляющие собой информационные корпоративные базы данных, предназначенные для подготовки отчетов, анализа бизнес-процессов и поддержки системы принятия решений. Хранилища данных служат также источником для оценки эффективности маркетинговых кампаний, прогнозированию, поиску новых возможных рынков и аудиторий для продажи, всевозможному анализу предыдущих периодов деятельности компаний. Как правило, хранилище данных – это предметно-ориентированная БД, строящаяся на временной основе, т.е. все изменения данных отслеживаются и регистрируются по времени, что позволяет проследить динамику событий. Также хранилища данных хранят долговременные данные — это означает, что они никогда не удаляются и не переписываются – вносятся только новые данные, это необходимо для изучения динамики изменения данных во времени. И последнее, хранилища данных, в большинстве случае, консолидированы с несколькими источниками, т.е. данные попадают в хранилище данных из нескольких источников, причем, прежде чем попасть в хранилище данных, эти данные проходят проверку на непротиворечивость и достоверность.

Здравствуйте всем!

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

Удобочитаемый синтаксис, прост в обучении, высокоуровневый язык, Объектно-Ориентированый язык программирования (ООП), мощный, интерактивный режим, масса библиотек. Множество иных плюсов… И это всё в одном языке.
Для начала окунёмся в возможности и узнаем, что же умеет Python?

David Drysdale, Beginner's guide to linkers (http://www.lurklurk.org/linkers/linkers.html).

Цель данной статьи — помочь C и C++ программистам понять сущность того, чем занимается компоновщик. За последние несколько лет я объяснил это большому количеству коллег и наконец решил, что настало время перенести этот материал на бумагу, чтоб он стал более доступным (и чтоб мне не пришлось объяснять его снова). [Обновление в марте 2009: добавлена дополнительная информация об особенностях компоновки в Windows, а также более подробно расписано правило одного определения (one-definition rule).

Типичным примером того, почему ко мне обращались за помощью, служит следующая ошибка компоновки:

g++ -o test1 test1a.o test1b.o
test1a.o(.text+0x18): In function `main':
: undefined reference to `findmax(int, int)'
collect2: ld returned 1 exit status

Если Ваша реакция — 'наверняка забыл extern «C»', то Вы скорее всего знаете всё, что приведено в этой статье.

Не секрет, что не одно поколение программистов зачитало до дыр книгу «Этюды для программистов» Чарльза Уэзерелла, оригинал которой на английском вышел аж в 1978.



Книга содержит 27 “этюдов”. Каждый этюд – это законченная содержательная задача для обучающихся программированию. Удивительно, книге более 30 лет, но любой из этюдов может быть до сих пор использован по назначению. Сам, будучи фанатом книги, до сих пор храню родной бумажный вариант русского издания, а относительно недавно таки приобрел оригинал на английском.

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

Волею судеб, недавно у меня появилась возможность связаться с Чарльзом и взять у него интервью.