Программирование *

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

• Инициализация типа: это код, который выполняется чтобы проинициализировать все статические переменные класса и выполнить статический конструктор;
• Циклическая зависимость: два кусочка кода, которые зависят друг от друга. В нашем случае это два класса, инициализация типов которых требует уже проинициализированного типа другого класса.

Ну и небольшой пример, чтобы показать, о чем идет речь:

using System; 
	
class Test 
{     
    static void Main() 
    { 
        Console.WriteLine(First.Beta); 
    } 
} 
	
class First 
{ 
    public static readonly int Alpha = 5; 
    public static readonly int Beta = Second.Gamma; 
} 
	
class Second 
{ 
    public static readonly int Gamma = First.Alpha; 
}

Результатом выполнения этого кода будет 0

Уже в субботу 19 мая пройдет вторая конференция для Scala-разработчиков в Санкт-Петербурге — ScalaDev.



В программе конференции гостей ждет доклады о новых возможностях Scala 2.10, байткоде, создании эффективной и асинхронной системы, используя модель актеров и Akka2.0, а также новом языке Kotlin.

Регистрация и подробная информация о конференции по адресу: scaladev.ru.

Мы с Vass записали и выложили четвертую серию подкаста «Заметки о Qt».

Сам подкаст на rpod.ru — qt-notes.rpod.ru/275603.html

Американское космическое агентство NASA недавно решило провести конкурс среди представителей ИТ-сферы в общем и программистов в частности. Суть конкурса — поиск интересных идей по использованию более, чем 100 терабайт накопленных агентством данных. Эти данные, касающиеся телеметрии космических устройств, изображений космического пространства и т.п., накоплены за 30 лет работы NASA. И хорошей идеи, как можно эффективно использовать все эти разрозненные данные, у представителей агентства пока нет.

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

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

Привет, Хабр. Меня зовут Александр. И я хочу поделится своей историей работы над одним крупным и сложным проектом.

В этой статье не будет кода и схем, в ней будет только история создания «от и до» самого проекта. Думаю, многим будет интересна данная статья. Итак, поехали!

Начало

Все началось летом 2011. На тот момент я был 3 года чистокровным фрилансером. То есть моя работа — это фриланс. Работал и работаю до сих пор только с западными заказчиками. Основная специализация — разработка проектов связанных с распознаванием образов, текста и т.д.

Все началось с того, что я, как всегда, с утра проверял почту, чистил спам, занимался рутинной работой. Обычно я не смотрю, что у меня в спаме, но тут я увидел письмо, с вполне реального адреса. Я открыл письмо, в котором одна компания искала программиста для допиливания крупного западного проекта. Причем эта компания требовала программиста именно из моего города и обязательно с опытом работы в области распознавания. Я ради любопытства ответил на это письмо. Буквально через час мне пришел ответ. А через два мы уже созвонились с менеджером проекта. Поначалу мне показалось, что ничего сложного в доработке нет, обычный набор функционала. После непродолжительного разговора с менеджером я огласил свой прайс, то есть ставку в час. И на этом мы попрощались. На следующий день мне сказали, что согласны на мой ценник и дали тестовое задание. Я его успешно выполнил в течении часа, и мы двинулись дальше. А здесь начинается самое интересное. Во-первых, меня пригласили в офис для того, чтобы подписать договор о неразглашении (Non-Disclosure Agreement). Во-вторых, и это логично, исходники проекта мне обещали отдать только после подписания договора. Если честно, меня это смутило, не знаю даже почему. И интуиция меня не подвела. Я потребовал хотя бы часть исходного кода, чтобы оценить сложность работы и попросил рассказать подробнее о проекте. Как оказалось проект на тот момент велся уже три года и я был 4 (!) исполнителем. До меня работала американская компания, потом индусы, потом компания, которая наняла меня, пыталась реализовать проект силами одной девочки-программиста, а потом это все чудо предложили разгребать мне. Меня это не просто удивило, а очень насторожило. Потом я узнал множество удивительных вещей, например о том, что заказчик 2 года не видел программу, а видел только скриншоты, а индусы кормили обещаниями этого заказчика. У меня не укладывалось в голове, как такое можно реализовать. Менеджеру индусов надо дать медаль «За находчивость».

После того как я выслушал удивительную историю, мы договорились с менеджером о том, что он мне отдаст исходный код и я оценю масштаб трагедии. Чтобы было более понятно, я расскажу более подробно о проекте. Этот проект — это инструмент для инженеров, архитекторов, электриков и других людей, которые занимаются строительством домов, небоскребов, одним словом зданий. Он служит для подсчета различных элементов на строительных планах, расчета площадей, измерения длин и составления смет. Грубо говоря есть строительный план и на нем есть розетки. Нам надо распознать и посчитать сколько этих розеток. Для распознавания использовалась библиотека написанная другим программистом. Сам проект написан на C#. Моя задача была собрать все воедино и доработать дополнительный функционал, а также привести программу к более менее стабильному состоянию. Кажется все просто и элементарно. Я тоже так подумал. Но не тут-то было.

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

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

1. Компоненты и контролы.

Проект очень сильно связан с графикой, но для ее вывода и обработки использовался обычный PictureBox. Самый маленький размер плана — 5400x3600 пикселей. Знающие люди поймут, что для PictureBox -это достаточно проблематичная тема с выводом больших картинок и их обработкой. Не стоит забывать, что помимо самих планов выводится еще много информации (площади, текст, найденные символы и т.д.). При запуске проекта с 5 маленькими планами, программа непременно падала с ошибкой «Out of memory». Что было очень большой проблемой, так как основной задумкой было то, что инструмент должен был работать по принципу «запустил и забыл».

2. Логика архитектуры исходного кода программы.

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

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

UPD: Новичкам советую обратить внимание на комментарии — там активно и аргументированно корректируется этот план.

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

Например в популярной CMS UMI мы можем найти такое замечательное наименование свойства объекта: izobrazhenie. Заметьте — не «image» и даже не «picture», а вот так незамысловато.

Недавно вышла книга The dRuby book — distributed and parallel computing with Ruby (перевод японской книги, написанной автором самой библиотеки). В этой статье я попытаюсь дать обзор глав книги, касающихся библиотеки DRb. Если вам захочется ознакомиться с темой более подробно, книгу можно купить или скачать. Сразу скажу, что я не буду говорить в этом посте ни о синхронизации потоков, ни о библиотеке Rinda.

Предположим, что вы пишите систему, которая работает с более чем одним процессом. Например, у вас есть веб-сервер, который в фоновом режиме запускает задачи, работающие долгое время. Или вам просто нужно обеспечить пересылку данных из одного процесса в другой и координировать их. Для таких ситуаций и нужна библиотека DRb. Она написана целиком на Ruby и включена в стандартную библиотеку, поэтому начать работать с ней можно моментально. Для её подключения достаточно написать require 'drb'

Достоинства библиотеки DRb большей частью проистекают из динамичности самого языка Ruby.
Во-первых, при затрате минимальных усилий на подготовительном этапе, дальше вы работаете с объектами не задумываясь, где они расположены: в одном процессе или в другом. Библиотека полностью маскирует от вас все технические детали.
Во-вторых, вы не обязаны жестко прописывать интерфейс. Любой руби-объект может выставить свой интерфейс наружу — таким образом вы можете как воспользоваться функциональностью одного из стандартных классов типа Hash или Queue, а можете сделать свой класс с любым интерфейсом. Кроме того вам ничто не мешает менять интерфейс прямо в процессе исполнения, и даже использовать method_missing для обработки любых запросов. И уж разумеется, обновление интерфейса сервера вообще никак не влияет на клиента, если тот не вызывает методы, которые изменили сигнатуру или поведение. Таким образом сервер и клиент максимально независимы.
И наконец, клиент даже не обязан знать классы объектов, которые ему возвращает сервер, он может их использовать и без этого. Таким образом сервер волен скрыть столько много деталей, сколько ему угодно.
Но, конечно, есть и подводные камни, и их предостаточно. К счастью, dRuby несложен в понимании, ну а понимание его устройства позволяет большей части проблем просто не допускать. Документация к этой библиотеке, к сожалению, не проясняет множества моментов, поэтому статья будет интересна и новичкам, и людям уже поработавшим с библиотекой.

Многие поклонники гаджетов уже сделали предзаказ мини-компьютера Raspberry Pi, а некоторые счастливчики уже получили эти устройства. Само собой, эти устройства, прежде всего, попали в руки девелоперов, программистов, гиков и любителей поработать с разного рода железом. И уже началась работа по изменению прошивки Raspberry Pi. Это не такой и простой процесс, и разработчик с ником Hexxeh сумел упростить все это. Он создал собственный инструмент, автоматизирующий процесс обновления прошивки.

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

Далее следует попытка выделить набор особенностей стандартного Common Lisp, кратко и с примерами.

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

Текст по большому счёту основан на списке особенностей CL и обзоре CL Роберта Стренда (Robert Strandh).

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

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

Мы все «немного читали» об оптимизации работы с памятью, и у нас отложилось, что полезно, когда «кэш остается горячим», то есть данные, к которым часто обращаются потоки, должны быть компактными и находиться в ближайшем к процессорному ядру кэше. Все так, но когда дело доходит до того, чтобы делиться доступом, потоки становятся злейшими врагами [производительности], а кэш не просто горячий, он аж «горит адским огнем» – такая во круг него разворачивается борьба.

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

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

При построении цепочек использовалась методология, описанная в статье “Автоматический анализ текстов без модераторов” и в комментариях к ней. После описания алгоритма будут предложена стратегия с положительным математическим ожиданием прибыли.

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

Отчасти эта скорость обусловлена удачей. Я использую виртуальный хостинг и не могу контролировать работу других сайтов на том же сервере.

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

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

Меня время от времени озадачивают вопросами в связи с мимолётной заметкой, которую я сделал в 2010, по поводу того, что я больше не программирую ради заработка. Это правда. Я не работал в качестве full-time программиста с 2003-го. Короткая версия этих вопросов — «Почему?». Более длинная версия — «Слушай, ты ведёшь супер-технический блог о программировании и, похоже, ты знаешь все эти штучки, но неужели ты не хочешь работать программистом?».

19 мая в офисе JetBrains состоится вторая встреча Scala-разработчиков в Санкт-Петербурге. Первая встреча прошла 1 октября, отчет с видео можно посмотреть по ссылке.



Подробнее о докладах на странице мероприятия или под катом.

Мероприятие бесплатное, для посещения необходимо зарегистрироваться.

В прошлые выходные (28-29 апреля) в Киеве состоялся финал мероприятия, которое носит название UA Web Challenge.

Мероприятие проводится в формате чемпионата и основной целью является объединение классных перспективных разработчиков с лучшими IT-компаниями на рынке; помочь айтишникам получить новый полезный опыт.

В этом году мы проводили мероприятие уже второй раз (анонс отборочного тура в событиях на хабре) и должен сказать, что в этот раз всё, что было задумано организаторами — удалось (или почти всё ;))

Как известно, с использованием фреймворка Qt написано немало программ, причём отечественных среди них в последнее время становится всё больше. Итак, что же было написано в России с использованием этого фреймворка?

Kaspersky Internet Security

Kaspersky Internet Security 2012 – решение для обеспечения оптимального уровня безопасности. Инновационная гибридная защита мгновенно устраняет вредоносные программы, спам и другие интернет-угрозы, экономя ресурсы компьютера за счет комбинации облачных и антивирусных технологий.

В папке программы обнаружил следующие модули: qtcore, qtdeclarative, qtgui, qtnetwork, qtscript, qtsql, qtwebkit.

2ГИС для iOS и Android

2ГИС – бесплатный электронный справочник организаций с картой города. 11 550 000 пользователей ПК в более чем 150 городах России и Украины регулярно используют 2ГИС в личных целях и для решения бизнес-задач.

Пруфлинк: «Оффлайновая версия 2ГИС разработана с использованием фреймворка Qt 4.8 и имеет нативный интерфейс, созданный в соответствии с Apple Human Interface Guidelines».