А-рабство в IT

Удивительно, но в узких отраслевых нишах IT-сектора - сохранились феодальные подходы.

Речь идет про рынок GIS-систем и программировании в этой области. А именно - посмотрим на компанию ESRI и ее программный продукт ArcGIS.

На первый взгляд - сайт компании радужно встречает программиста, а если вы зарегистрируете глобальный аккаунт разработчика - то вам начинают слать "письма счастья", а именно - "Начни программировать уже сейчас!", "Опубликуй свое приложение!", "Размести свое приложение в Marketplace ArcGIS" (цитирование почти дословное). Идем дальше - на сайте, на ваш выбор, широкий спектр IT-технологий программирования, которые вы можете использовать (делая плагины к основному продукту, или создавая самостоятельное приложение) - здесь в наличии и Java, и .NET, и т.д. и т.п. Даже плагины для Eclipse и MS Visual Studio для вас подготовлены. А так же что-то пишется про разработку под мобильные платформы.

В чем же подвох, спросите вы? - А вот в чем - чтобы создать более-менее интересное приложение - вы должны купить годовую лицензию разработчика. В которую входят desktop- и серверная версии основного программного GIS-продукта - ArcGIS, а так же фреймворки подключения к нему (которые просто так, не купив подписку - вы скачать с сайта не сможете ни под каким соусом). И вот за все это, оптом - компания делает оптовую скидку, и вы должны сначала заплатить, а только потом попробовать программировать.

Вы скажете - так а как же информация на сайте, и "письма счастья"??? - Так а там предлагается или подключиться к облачной технологии компании (с лимитом на число обращений, если бесплатно; хотя супер-минималистическая функциональность есть и без лимита). Или там еще какой-то бесплатный бутерброд есть:
1) Вы скачиваете 2-ух месячную триал-версию основной программы.
2) В среде ПО из п.1 - подготавливаете какой-то "runtime" (вероятно речь идет о слоях, в которых вы размещаете GIS-информацию).
3) Скачиваете что-то, напоминающее минималистическую бесплатную версию фреймворка.
4) Используя п.3 - подключаетесь ко внутренней структуре "runtime" из п.2.

Вряд ли ваш потенциальный работодатель, или заказчик - оценит подготовленный вами пример, ведь "за бесплатно" - вы сможете попробовать программировать - с использованием только 5-10% функционала.

Кто-то скажет - ну а почему бы и не купить годовую подписку разработчика? - Понимаете, дело еще в чем - вы должно еще разобраться в самой предметной области (это на месяцы, в общем случае). Потом вы должны разобраться в самой программе ArcGIS, для которой хотите программировать (на это тоже уйдет время, при чем вы будете оперировать космическими снимками и новыми для себя плагинами). Потом - разобраться в "полноценных" возможностях программирования для всего этого. И вы заранее не знаете в точности - с какой скоростью и глючностью у вас будет все в итоге работать. Это как новичку в SQL - предлагать сначала купить СУБД Oracle, и только потом, с помощью купленного - пробовать изучить SQL.

P.S. Есть еще вариант, когда вы студент ВУЗа, и если этому ВУЗу компания ESRI продала по льготной цене полную версию всего этого - тогда вы сможете полноценно что-то попробовать. Однако я сомневаюсь, что студенты отраслевых ВУЗов, на которую нацелено это GIS ПО (природоохранные и прочие) - разбираются в Java, СУБД и т.д. Компания искусственно сдерживает привлечение программистов под свой программный продукт.

Акция, бесплатная версия - Adobe Creative Suite 2

Ссылка на страницу скачивания (офф. сайт), там же официальный серийный номер.

Обновлено: представитель Adobe - "No, You Can't Download Adobe CS2 Applications For Free".

Акция, бесплатная версия - Ashampoo Burning Studio 2013

Ссылка на страницу акции (офф. сайт).

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

Шпионы разума

Попался тут рекламный баннер от mail.ru:




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

Давайте колбасу назовем химическим составом с пищевыми добавками и красителями и попробуем снабдить ценник таким названием. Особо внимательные покупатели просто покрутят пальцем у виска.
 Купят ли? - Это другой вопрос. Я бы химический состав не покупал...

P.S. Компания mail.ru в кризис 2008-2009 гг. не увольняла, а набирала программистов, плюс это одна из немногих IT-компаний, которая может нормально общаться с IT-общественностью. Поэтому не будем излишне строги. Косяк, ну и ладно.

Ужас белорусского программиста

TDD

В Минске пройдет семинар по TDD.

Посмотрел программу, лично меня не впечатлило.

Но кто впервые с этим сталкивается и на данный момент считает, что TDD - это просто некая мода - тому посетить нужно.

Лично я применял TDD, хотя и в ограниченном виде. Как методологию разработки для многих проектов - оцениваю как полезную.

Все принципы полезности выводятся из самого подхода к разработке. А подход, самый правильный, такой:

1) Use cases и фиксация багов. Отображаются в софте с он-лайн доступом. Когда вы можете продемонстрировать своим акционерам или просто начальству (финансирующему вас) - как у вас что движется - это большое дело. Не нужно размахивать руками и говорить как много вы сделали - покажите список выполненных фич и закрытых багов. Директор или акционеры, или сообщество - может/могут провести независимый аудит - как вам что удается. Важность отчетности, как результатов работы - нельзя не переоценить. Вы сможете потом вздохнуть спокойно или апеллировать ко мнению независимых технических специалистов. На этой отчетности вскроются все недостатки ваших проект-менеджеров (почему в первую очередь делаются второстепенные фичи? почему с марта по июль у вас закрыто только 2 бага - что, ушло 3 разработчика, может это проект-менеджер конфликтный, давайте разбираться), вскроется - чем руководствовался исполнительный директор, нанимая проект-менеджеров, равнозначно ли учитываются мнения "бизнес-стороны" (топ-менеджеров, акционеров) и технических специалистов (тим-лид, архитектор, разработчики). Не бывает безсбойной работы - сбои обеспечены. Но если вашему директору глубоко все равно, что творится со списком use cases - значит "рыба гниет с головы" - расслабьтесь и получайте удовольствие - причина всех дедлайнов и мата - не в вас. Но чтобы апеллировать к чему-то (на одной фирме, где я работал - приехал акционер, разобраться, почему сбиваются сроки) - вы должны вести отчетность. Вы тогда сможете всегда доказать. Это - ваш гарант спокойной жизни. Пускай ваш проект-менеджер висит по пол дня в соц. сетях и аськах - главное, чтобы вы вели отчетность, показывающую ВАШУ работу, реальную работу. С этой точки зрения - вам потом по-боку будет удаленная работа - вы каждый день сможете присылать отчеты, и по результатам месяца - из ваших отправленных e-mail-ов - создавать консолидированный отчет - что вы сделали за месяц. Пускай на фирме есть любимчики - вам это по боку, В СЛУЧАЕ ЕСЛИ ВЫ ВЕДЕТЕ ОТЧЕТНОСТЬ. Ваш директор не акцентирует на этом внимание, что нужно вести - ведите сами. Когда вас позовут "на ковер" из-за того, что кто-то где-то по сроками или чему еще завалил - вам достаточно будет собрать ваши отчеты за нужный период. Списки фич закрывались? Баги закрывались? 10 штук в июне, 14 штук в июле, в августе у вас был отпуск? - Покажите свой отчет, пришлите директору "консолидированный" e-mail с этой информацией. Директор абсолютно не в курсе, что вы делали и делали ли - убедите фактами. Есть факты - вопросы будут к другим.

2) Тесты в TDD помогают продемонстрировать выполнение фич и закрытие багов из п.1. Они придают вашей отчетности в этом - новое значение - независимые разработчики, использующие ваш API - могут с каждой вашей ревизией в SVN - видеть - закрыты ли баги, фичи и протестировать свои дополнения к вашему продукту - будут ли с их прибамбасами выполняться ваши тесты.

3) Тесты для каждодневно изменяющегося GUI - напрасный расход ресурсов. Директору очень хочется - пускай нанимает отдельного тестировщика под GUI. Есть у него финансирование для этого дела - его право. Нет - вы будете 2/3 времени тратить на тесты, завалите список фич. Объясните директору - что вы будет работать в 3 раза медленнее из-за этого. Если он согласен - потом к январю, когда его возьмут за жабры акционеры - перешлите ВАШ E-MAIL, в котором вы информировали его об этом (и его ответ). Крайним должен быть он, по определению. ;)

4) И еще раз п.1. Если не понимаете, что вам платят представители бизнеса и что им постоянно нужна отчетность - попробуйте заняться изучением экономики. Не бывает сферического разработчика, занятого каким-то программированием в себе. Кому-то будет делегирована функция (проект-менеджеру) - проверять, как тратятся чужие деньги за ваш труд. Но т.к. проект-менеджер может быть ленивым, директор - дураком и подлецом - ведите отчетность. "Умоете" всех и надолго. Вот - ваше место и роль в данной точке пространства и времени. Если вам кто-то что-то спускает - не расслабляйтесь. В другой фирме вас возьмут "за жабры", выработайте правильный подход изначально.

:)

Миф об оптимизации IT

(пост был написан 24 апреля 2012 г.)

После кризиса 2008-2009 г. редакция CNews освещала круглый стол, с участием руководителей IT-подразделений российских банков (ссылку сейчас не нашел, но ниже будут аналогичные ссылки). Практически все повторяли одну и ту же магическую формулу - ОПТИМИЗАЦИЯ IT. О необходимости, полезности ее, и т.д.

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

Цитата на эту тему:

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

Между тем, ошибочность такой позиции была очевидна и тогда, цитата от другого представителя IT:

"Кризис вынудил банки более критично взглянуть на вопрос окупаемости и экономической целесообразности проектов. Отказ от «ИТ-долгостроя» и проектов, эффективность которых сегодня оказывается под сомнением, - это сегодня далеко не единственный способ экономии ИТ-бюджетов. К сожалению, на первый план зачастую выходят кадровые рычаги снижения издержек на ИТ – сокращение персонала, снижение зарплат и другие непопулярные в рядах ИТ-специалистов меры. Но такой подход не всегда позволяет сохранить прежнюю эффективность ИТ-подразделения, не говоря уже о повышении отдачи этой структуры в ситуации, когда банк ведет борьбу за выживание. «Сокращение проектов, ИТ-бюджета, персонала, -  все это приводит снижению качества оказываемых банку ИТ-услуг. Лозунги, которые сейчас произносят многие топ-менеджеры на тему повышения эффективности работы и снижения издержек - это сплошная профанация, - убежден Роман Агнцев. - Банки всегда были коммерческими организациями, их главной целью было получение прибыли. Соответственно, ИТ-процессы были построены максимально эффективно. Если топ-менеджмент считает, что это было не так, что ИТ-директора и раньше имели возможности для оптимизации, но не воспользовались ими - пусть они объяснят акционерам банка, почему так происходило»."

К чему мой пост? В сегодняшней программе РБК "Рынки" (14-18 мск) в прямом эфире телезритель задал вопрос. Суть его в том, что Альфа-банк сейчас навязывает кредиты, в том числе и неплатежеспособным лицам.

- Ждем следующей весной новых заявлений о необходимости оптимизации IT.

Взбесившийся торговый робот

Что лучше - SQL или NoSQL

Почему NoSQL может быть лучше:

1) Фантастическая простота. Не нужно учить SQL, все операции сводятся к манипулированию операторами get/set при работе с ключами, которые вы и сохраняете. Научиться новым операторам для этого можно буквально за 2 минуты.

2) Быстрая работа. При этом, на сколько я понимаю, для уменьшения стоимости и обхода требуемости несуразного числа NoSQ-серверов  - используются не только модули ОЗУ, но и твердотельные накопители, следующий уровень - обычные накопители на жестких дисках. Во всяком случае все поставщики NoSQL это могут реализовать, если этого где-то нет, это не проблема (свопим на винт редко изменяющиеся данные, что тут сложного).

3) Администрировать NoSQL-решения проще, чем заниматься репликациями СУБД (речь идет про обслуживание огромного кол-ва пользователей - от десятков тысяч, до миллиона; именно здесь уже появляются всякие репликации и т.п.).

4) Быстрое реконфигурирование кластера серверов, включение новых, выключение и т.п.


Почему SQL может быть лучше:

1) У NoSQL работа с атомарностью операций добавления/удаления значений - не так проста, как кажется. Приходится использовать всякие трюки. Что в итоге приводит к усложению. А при увеличении сложности вашего приложения - каждая имеющаяся сложность может увеличиваться в геометрической прогрессии.

2) У NoSQL вообще могут быть проблемы с многопоточностью. Как вы собираетесь обходить ее? С "помощью" "простых" операторов get/set-? Простейший вариант обхода - установление какого-то общего правила,  универсального. При этом теряется гибкость. Вы - яркая индивидуальность, или "такой как все"? Последнее и есть универсальность, яркая - гибкая настройка, в бесчисленном количестве вариаций и взаимоотношений внутренних частей.

3) Транзакционность. В NoSQL у операторов get/set - ее нет. :) Все, приплыли, приехали, одними операторами get/set не обойтись, нужны дополнительные средства. Какие? Как их реализовать? Как их реализовать в простом NoSQL, когда, фактически - у вас в наличии есть только возможности самого элементарного скрипта (запихнуть ключ в массив, отправить массив на хранение, получить назад массив, разобрать его средствами foreach).

4) Все равно в NoSQL мы видим все те же "плоские таблицы" и отношения между ними. Ведь сохраняются в NoSQL - массивы. Элементы этих массивов - это какие-то значения, которые зачастую являются ключами. Ключами к каким-то другим сохраняемым массивам, в NoSQL. Те же "плоские таблицы", но вид чуть сбоку.

5) Поиск в NoSQL. Реализован не везде, хотя где его нет - обещают в ближайшее время. И как же его эффективным то сделать, если сохранять в массивах - и числа, и строки? Фактически мы уже пришли к необходимости SQL, т.е. он "не просто так" придуман, а решает, эффективно решает - все эти пункты.

6) Распарсить полученные данные из NoSQL (и затратить на это процессорное время сервера приложений) все равно придется. Тут мы приближаемся к JPA, ORM.

7) Лучшие СУБД (в лице, например, Oracle) - "выносят" в ОЗУ очень много всяких кэширующих структур. Чем и достигается отличная производительность. И в этом моменте - "стирается", во многом, грань между NoSQL и SQL. Тем более есть (в том числе у Oracle) - СУБД, которые работают только в ОЗУ (а так же позволяют производить "связку" с "обычной" СУБД), если вам это надо.

8) Сложно представить, что произойдет в NoSQL при малом числе серверов и одновременном выходе из строя нескольких из них. Это решается механизмом репликации и подключением традиционной СУБД, куда иногда будут сохраняться все данные. Ну и циферка на последок о наработках на отказ в огромных кластерах, а вернее не кластере - а суперкомпьютере "Ломоносов" (самый быстрый российский суперкомпьютер) - в неделю летит по 2 узла (в данном случае "узел" - это, вероятно, 2 процессора и их общая память). В Европе лучше, там, кажется - 1 такой "узел" - в 2 недели вылетает. Для суперкомпьютеров каждая такая поломка вообще критична, так как нарушается "единое поле" вычислений, но в данном случае - пускай у нас кластер - все равно содержание большого числа серверов под NoSQL будет влетать в копеечку.

9) А что такое есть SQL-? А такой же убогенький язык скриптов. Ну так в чем, тогда, разница? :)

Возможно тут не все доводы, поэтому и напрашивающиеся выводы - могут быть не совсем верными.

Представитель Microsoft прокомментировал мои наблюдения на счет функционального программирования.

Вот ссылка. В принципе там нет ничего, что опровергало бы мои доводы, изложенные чуть ниже.

Функциональное программирование, свежий взгляд на вещи (часть 2)

2-ая часть обсуждения. Обратимся к Википедии. Избранные цитаты из нее:

"Функциональное программирование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании). Противопоставляется парадигме императивного программирования, которая описывает процесс вычислений как последовательность изменения состояний (в значении, подобном таковому в теории автоматов). Функциональное программирование не предполагает изменяемость данных (в отличие от императивного, где одной из базовых концепций является переменная)."

"Многие нефункциональные языки, такие как C, C++ и C# могут вести себя как функциональные при использовании указателей на функцию"

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

"Привлекательная сторона вычислений без состояний — повышение надёжности кода за счёт чёткой структуризации и отсутствия необходимости отслеживания побочных эффектов. Любая функция работает только с локальными данными"

Какие отсюда следуют выводы?

1) Очевидно, что ФП и ООП - мягко говоря, слабо совместимы.

2) Очевидно, что ФП подразумевает, на практике, процедурный подход в программировании. Нюанс, о чем не указано в Википедии - что вы передаете не объекты, а функции, в теле программы, что вы ВЫНУЖДЕНЫ будете использовать подпрограммы.

3) Давайте уберем из ФП - функции, оставим одни переменные, и тогда получим не 2D-программирование, а 1D-программирование. Вот вам и та часть Ассемблера, в которой мы присваиваем переменные в регистрах (другие возможности Ассемблера сейчас опустим).

4) Можно и не использовать процедурный подход при программировании в ФП. В таком случае "весь поток выполнения программы" - будет представлять собой постоянное присваивание и рекурсивные вызовы там, где нужно обработать циклом.
Это уже вообще НЕЧТО. - Если не заботиться о том, чтобы некоторые фрагменты кода можно было использовать несколько раз (а тогда получается процедурное программирование).
И это "круто"?! :)

Функциональное программирование, свежий взгляд на вещи (часть 1)

По моему скромному убеждению, функциональное программирование, это, своего рода - 2D-программирование. В программировании, с использованием ООП, у нас есть не только функции (методы), но и классы. Это дополнительное измерение (классы) - и дает 3D.

Это в контексте самого стиля программирования.

Бывают и функциональные языки, например в MS Visual Studio 2010 был введен фунциональный язык программирования F#.

Кратко его можно охарактеризовать так - "write once" (написал один раз, потом фиг разберешь что написал).

Из функции стараются сделать объект, которым и пытаются оперировать, поелику это представляется возможным. Со всеми вытекающими.

Здесь можно выделить 2 следующих момента:

1) Функциональные языки программирования зародились ранее, чем ООП-подход. Устаревшее, успело развиться, и раз уцелело до наших дней, значит там не только "попытки разными путями придать функции 3D-измерение", некоторые вещи там могут показаться любопытными.

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

Забавный материал прилагается

P.S. В древние времена были популярны шаманы, пытающиеся толковать те или иные природные явления, что они означают. Позднее некоторые наблюдения вошли в обиход - "Солнце красно с вечера - моряку бояться нечего", "Солнце красно по утру - моряку не по нутру", "Если чайка села в воду - жди хорошую погоду", "Чайка ходит по песку - моряку сулит тоску". Почувствуй себя шаманом - интерпретируй результат Google.

Многопоточность. Барьеры

Применение барьеров наиболее легко проиллюстрировать на примере работы с API CUDA. При этом зачастую применяется параллелизм на уровне данных:

1) Например есть большой массив, обработку которого мы хотим распараллелить. Этого можно достичь путем передачи каждому потоку видеокарты - обработку небольшой части этого массива. Тогда все потоки обработают весь исходный массив целиком.

2) Перед тем как обрабатывать, данные сначала нужно "подробить" на "порции" для каждого потока.

3) Загрузить каждую такую "порцию" в память видеокарты.

4) Перед обработкой каждого кусочка исходного массива - зачастую нужно убедиться, что он уже целиком загружен в память видеокарты. - Например есть такие вычисления, при которых нужно учесть "соседние" данные. Как же убедиться, что "соседние" потоки - тоже получили свои данные? - Обобщая на всю задачу - как убедиться, что ВЕСЬ исходный массив, пусть и дробленный на "кусочки" - но загружен в память видеокарты?

5) Для решения п.4 - мы просто указываем в коде потока - вызов барьера. - Пока все потоки не "подойдут" к этому месту кода (началу вычислений, которые следует после загрузки своей порции данных) - потоки будут блокироваться у барьера. Как только все потоки подойдут к барьеру - только тогда барьер позволит им всем "двигаться дальше".

Примерная логика работы потока:

1) Инициализация каких-то первоначальных переменных данного потока. Здесь же поток получает информацию о своем номере, а по своему номеру - он уже может однозначно указать какая именно часть исходных данные ему нужна из массива исходных значений.

2) Команда на загрузку своей порции данных.

3) Вызов функции барьера.

4) Начало обработки своей порции данных.