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

Так какого же чёрта моё прекрасное IT превращается в детский сад «Весёлый Програм-Мишка»?

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

Для начинающих поясню, что миграция идет по такой схеме: источники → преобразование данных (отвечает ETL или шина) → приемник.

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

Содержание

1. Введение в Computer Science
2. Структуры данных и Алгоритмы
3. Системное программирование
4. Распределенные системы
5. Базы данных
6. Объектно-ориентированный дизайн и разработка софта
7. Искусственный интеллект
8. Машинное обучение
9. Веб-разработка и интернет-технологии
10. Concurrency
11. Компьютерные сети
12. Разработка мобильных приложений
13. Математика для программистов
14. Теория информатики и языки программирования
15. Архитектура компьютера
16. Безопасность
17. Компьютерная графика
18. Работа с изображениями и компьютерное зрение
19. Интерфейс Человек-Компьютер
20. Вычислительная биология
21. Прочее

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

Краткое содержание статьи:

• Простейший тест: способы измерения теста, выбор статистики (квантили, медиана, среднее).
• Параметризованный тест: оценка сложности алгоритма, применения МНК к оценки линейности теста.
• Тесты на многоядерных машинах: сложность экстраполяции результатов тестов на многоядерные машины, закон Амдала и целесообразность измерений.
• Поведенческий тест: каким, при заданной модели поведения пользователей, будет время ожидание запроса и что может привести к коллапсу системы. Пропускная способность (throughput) и как его считать.
• Удивительное статическое распределение результатов performance теста.

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

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

Решение — под катом.

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

Итак, имеем карандаш:

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

При этом, учитывая мою профессиональную деформацию (я более 10 лет занимаюсь тестированием), рассматривать эти вопросы я буду на примере вполне конкретных ошибок, которые я наблюдала со стороны или допускала сама.

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

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

Если вы знаете, как валидировать email-адрес, поднимите руку. Те из вас, кто поднял руку — опустите её немедленно, пока вас кто-нибудь не увидел: это достаточно глупо — сидеть в одиночестве за клавиатурой с поднятой рукой; я говорил в переносном смысле.

До вчерашнего дня я бы тоже поднял руку (в переносном смысле). Мне нужно было проверить валидность email-адреса на сервере. Я это уже делал несколько сот тысяч раз (не шучу — я считал) при помощи классного регулярного выражения из моей личной библиотеки.

В этот раз меня почему-то потянуло ещё раз осмыслить мои предположения. Я никогда не читал (и даже не пролистывал) RFC по email-адресам. Я попросту основывал мою реализацию на основе того, что я подразумевал под корректным email-адресом. Ну, вы в курсе, что обычно говорят о том, кто подразумевает. [прим. перев. Автор имеет в виду игру слов: «when you assume, you make an ass out of you and me» — «когда вы (что-то) подразумеваете, вы делаете /./удака из себя и из меня»]

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

Каждый из нас знает, насколько MS Word удобный инструмент для подготовки небольших документов. И каждый из тех, кто сталкивался с подготовкой документа, количество страниц в котором превышает сотню (плюс необходимо придерживаться строгих требований к форматированию), знает об основных недостатках этого инструмента. Мне пришлось в своей жизни столкнуться с версткой 500 страничного документа, причем количество и расположение рисунков таблиц и формул в нем постоянно менялось от версии к версии. Я бы хотел поделиться своими «лайфхаками», которые мне пришлось применить при верстке этого документа. Некоторые из них мне подсказали друзья; на некоторые наткнулся на форумах; некоторые придумал сам.

Эти простые хитрости помогут вам при верстке диссертации дипломной работы или отчета.

В данной статье рассмотрены решения проблем:

• создание списка литературы
• Склонения перекрёстных ссылок на рисунки таблицы и формулы
• Перенос таблиц на новую страницу
• Вставка формул

В свете последних событий, связанных со Skype (блокировка «старых» версий клиента, насильное обновление клиентов на всех платформах, откровенно сырая новая версия клиента для Linux), решил поделиться с сообществом успешным опытом использования Google Hangouts для коллаборации (командной разработки ПО, парного программирования) и написать универсальное руководство (tutorial, how-to) для Debian/Ubuntu Linux, а также Mac OS X и Windows, собрав всю необходимую и полезную информацию воедино.

Эта статья для тех, кто в поиске полноценной альтернативы Skype для большинства современных платформ и в первую очередь для Linux.

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

1954-1959. Высшее образование

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

Факультет кибернетики открылся только десять лет спустя, а пока что мехмат готовил специалистов по математике и теоретической механике. При поступлении не было разделения по будущим специализациям — первые два курса учились все вместе, а на третьем делились по специальностям. Бабушкин выпуск 1959 года был первым, в котором появилась специализация «вычислительная математика». В рамках этой специализации читались теоретические курсы, совершенно новые для того времени: программирование, устройство аналоговых машин, устройство цифровых машин, вычислительные методы (в основном методы решения дифференциальных уравнений и задач линейной алгебры)… На лекции ходили не только студенты, но и сотрудники Вычислительного центра Академии наук — других источников нового знания часто не было.

Компьютерами всегда занимались в основном мужчины, так?

А вот и нет.

В 1987 году 42% американских разработчиков ПО были женщинами. И 34% системных аналитиков тоже. Компьютерные науки начали привлекать женщин в середине 60-х, на заре компьютерной эпохи. В то время мужчины уже доминировали в других технических специальностях, но не в компьютерной среде. На протяжении почти двух десятилетий процентное соотношение женщин с дипломом в области компьютерных наук стабильно росло и достигло пика в 37% в 1984 году.

По мотивам недавно прошедшей конференции в ЯрГУ 25 марта, на которую пришло уж очень немного народу, решил я написать небольшой мотивирующий пост для студентов и начинающих программистов/IT специалистов. Мою презентацию с доклада можно посмотреть на skydrive. Здесь же я постараюсь вкратце, на сколько это возможно, осветить этот доклад.

Это чисто мой полет мыслей, ни на какое откровение или новизну я не претендую. Начал я его писать сразу же после конференции (месяц назад), но все как-то не мог закончить. Радует безумно, что кроме меня со студентами и начинающими разработчиками хотят делиться все. Вот только в последние пару недель замечено два топика с похожими темами (и тоже стенограммы с конференций):

• Александр Бындю – Карьера в IT
• Яков Сироткин – Как стать героем

Ну и до нас не раз еще поднимали эту тему. Рекомендую читать и заряжаться всеми этими топиками.

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

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

Этой статьёй хочу выразить протест против устоявшейся практики преподнесения себя соискателями и предложить этому «раболепию по гайдлайнам» какую-то разумную альтернативу.

Статья для соискателей.

Перевёл после прочтения комментариев к статье «О ненависти к C++». В цитатах можно найти ответы на большинство возникших там вопросов.

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

49. Lisp — это не язык, а строительный материал.
— Alan Kay

48. Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.
— Edward V Berard

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



   Однако всегда вызывали интерес подобные «шпионские штучки», которые вполне бы могли найти себе применение в нашей повседневной жизни. Бывают ли такие устройства как в кино? Предлагаю свой новый обзор.

Эта статья о том, как можно сделать менеджер закладок используя Google Mail и Google Docs.
При этом Вы их никогда не потеряете (даже удалив из GMail, копия останется в Docs), а добавление нового URL будет происходить в два клика!

После поста о восстановлении флешек, оказалось, что у многих теперь есть рабочие, бесхозные флешки, которые обязательно нужно задействовать. Почему бы не сделать из них загрузочные флешки с дистрибутивами необходимых ОС? Это может здорово пригодиться при установке/переустановке операционных систем на нетбуки, где отсутствуют приводы оптических носителей. А иногда может даже ускорить процесс установки и сделать его намного тише на компьютере, где привод есть.
Хотя на Хабре уже описывались варианты создания загрузочных флешек, но вариант, который предлагаю я — слишком прост и по своему универсален, чтобы обойти его стороной.

Добрый день, Хабр!

Вчера я написал топик посвящённый управлению программным обеспечением как важным активом предприятия.
Если кто ещё не видел — можно ознакомиться тут — habrahabr.ru/blogs/soft/97343

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

Первый вопрос с которого продолжу — учёт бесплатного и свободного ПО в организациях.

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

Кратко о программе

О программе «Энергия — Буран» написано немало, я бы порекомендовал всем интересующимся сразу отправиться на специальный сайт buran.ru, на котором очень много достоверной информации.

Если вкратце резюмировать, то программа «Энергия — Буран» предусматривала создание универсальной тяжелой ракеты-носителя «Энергия» стотонного класса и, в качестве полезной нагрузки для нее — орбитального многоразового корабля «Буран».

Корабль «Буран» во многом был аналогом американской системы Space Shuttle: крылатый и бесхвостый планер, плиточная теплозащита, грузовой люк, сходные массо-габаритные параметры (вывод 30 тонн и возвращение с орбиты 20 тонн груза, экипаж до 7 космонавтов), но, поскольку техника не стоит на месте, а наш корабль разрабатывался позже, имел и существенные отличия. «Буран», в отличие от американского аналога, был изначально предназначен для стыковки с орбитальными станциями и другими кораблями, имел систему спасения экипажа (ее отсутствие погубило в свое время экипаж «Челленджера»), и, самое главное — мог выполнять задачи выхода в космос, работы на орбите и посадки в полностью автоматическом режиме.