Американский стандарт интеллектуальных транспортных систем U.S. Dot ITS описывает весь комплекс автоматизированных систем управления транспортом. Стандарт настолько масштабен, что втиснуть его описание в один или даже два поста нереально. Так как большинство описанных в нем систем для нас недостижимое светлое будущее, то и делать этого не стоит. А вот что стоит сделать — это рассмотреть то, как он устроен изнутри, какие находки сделали неизвестные американские (ой ли?) ИТ-специалисты, проделавшие весьма значительный объем работы за счет налогоплательщиков.

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

Введение

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

Как бы то ни было, неплохо бы разобраться в том, что же собой представляют ИТС и для чего они предназначены. Опустим транспортную и политическую составляющие и сосредоточимся на «Айтишной». Разберем на самом высоком уровне архитектуру ИТС и коротко пробежимся по основным ее блокам. Заодно системным архитекторам будет любопытно узнать, как вообще строится архитектура систем масштаба страны.

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

Каждый, кто хоть как-то причастен к созданию музыки, рассказов, фотографий и прочих произведений искусства (ну, или того, что он считает таковыми), опасается того, что его гениальное произведение «украдут». То есть, просто возьмут и перепубликуют, со ссылкой на автора или без. А то и начнут зарабатывать на этом деньги. Опасения эти небезосновательны: «пиратство», несмотря на все меры по борьбе с ним, процветает. Однако, мы сейчас не будем касаться вопроса о том, как правильно подать иск в суд. Поговорим об одной услуге, которую оказывают таким боязливым авторам самые разные организации и частные лица – о так называемой «регистрации» или «депонировании» произведений.

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

Начинающие программисты (а вполне возможно, что и их коллеги с опытом), должно быть, часто спрашивают себя, нужно ли им учить JAVA, или знания JavaScript, Python или Ruby будет вполне достаточно в современном мире. Учитывая спрос на программистов в нынешней экономике, многие находят достойную работу еще учась в университетах, и зачем тогда, спрашивается, представителю этой профессии заглядывать в такое далекое прошлое, как COBOL?

Согласно исследованию Gartner от 2001 года (в случае с данным конкретным языком это вполне можно назвать «недавно»), 85% мирового объема бизнес-информации обрабатывалось на языке COBOL, а к текущему моменту объем кода, написанный этим языком программирования, начинает снова увеличиваться. Компания Micro Focus, занимающаяся разработкой и продажей инструментов модернизации COBOL, заявляет, что 70% мирового бизнеса до сих пор активно использует этот язык.

И хотя очевидно, что многие из приложений, изначально написанных на COBOL будут переписаны, в Micro Focus уверены, что большая часть оригинального кода все-равно останется в ходу, а приложения будут использоваться еще долгие годы. Они безопасны, стабильны, а компании использующие их, не готовы от них просто так отказаться. Программный менеджер Micro Focus по имени Арунн Рамадосс (Arunn Ramadoss) говорит: «Ни один другой язык неспособен представлять бизнес-данные так точно, как это делает COBOL».

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

Понятно, что напрашивающийся (и правильный) ответ — «Потому что код приходится не только писать, а и читать». Едва ли этот ответ стоит целого поста, но автор им не ограничивается.

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

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

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

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

Раз уж нам с вами предстоит пройти некоторый путь вместе, позвольте представиться. Меня зовут Алексей. По специальности я инженер-системотехник, профессиональный сисадмин. Окончил профильный ВУЗ в 1999 году, 6 лет работал системным инженером, потом 3 года специализировался в менеджменте в области ИТ, а потом нашел себя в роли бизнес-аналитика.

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

Надо сказать, коллеги, что эта работа — просто рай для любителей игры Sim City и Transport Tycoon. Где еще вам представиться возможность построить транспортную систему целого города? И не на экране компьютера, а живьем.

Конечно, не все в этой отрасли радужно и прекрасно. Особенно в нашей стране. Далее о проблемах.

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

Всё началось с того, что в один прекрасный момент у меня пропал звук на ноутбуке, к слову сказать, что моему старичку Acer 2492 WLMi уже потопал 4 год, и за время использования с ним ничего страшного не случалось, максимум, что менял термопасту. Что сказать, живучий зараза. В отличии от моих новых машин.

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

У меня давно была мечта написать карты. Удобные карты, которым не нужен доступ в Интернет, с актуальными данными, быстрые и работающие на любом устройстве. После работы инженером в Google Maps эта мечта только усилилась и в какой то момент переросла в конкретные действия.

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

Одним прекрасным утром к нам в офис забежал молодой парень, с амбициозной идеей и “средствами для реализации” в кармане. “Заходишь на сайт, а там — телевизор. К нему можно подключиться через свою web-камеру. Одновременно может вещать только один человек, остальные — ждут своей очереди (но можно посмотреть скриншоты с их вебкамер). Задача каждого — удержаться в эфире, как можно дольше. Если выступающий нравится публике — все жмут “Cool!”, если подкачал — “Go away!”. И человек заменяется на следующего в очереди. Ну и можно в чат писать”.

Хорошая идея — драйвовый проект. Рисуем прототип, решаем реализовать обновление чата, списка пользователей, рейтинга и т.д. с помощью push-технологии. Это когда после загрузки страницы соединение между клиентом и сервером не закрывается, а продолжает использоваться для отправки сервером каких-либо событий на клиента.

Осторожно! Эта шняга может убить ваш сервер! Кстати, если вы вдруг решите написать высконагруженный скандинавский аукцион – истина и веселые картинки где-то рядом, под катом.

Уважаемые Хабрачитатели.

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