Записки искателей

Спросите у 100 программистов “Какой вы хотите видить свою профессиональную деятельность через 5-7 лет?”

50 из них ответят - “стану project-менеджером, а 50 - “открою открыть свою фирму”.

Конечно скорее всего найдутся и те, кто захотят добиться других высот (стать начальником отдела, сотрудником корпорации с мировым именем, etc.), но большиство ответит именно так.

С одной стороны такие желания логичны.
Если взять первых 50 - программист видит что его начальник, такой же программист как и он, но с 10-15 летним стажем. Потому уверены что сначала они будут Junior-девелоперами, потом Senior-девелоперами, а потом PM.
Последние лет 10 чаще всего именно так и происходит.
Причиной тому является нехватка квалифицированных менеджеров. А упоминать о дифиците технически-грамотных менеджеров уже как-то даже неприлично.

Вторыми 50-ю движет мысль “Не хочу всю жизнь спину гнуть на чужого дядю” или “Свой бизнес приносит больше доходов” или “Вон у Васи своя фирма, а я все ещё за зарплату тружусь” и тд и тп.

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

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

На Java.net завершился опрос “Какой не Java-язык вы хотели бы запускать на платформе JVM?”.

Я ожидал что будет очередное флеймообразующее обсуждение из серии “какой язык лучше”, но так не случилось.

Показательно, что по результатам лидирует Groovy. Но этого наверное и стоило ожидать в связи с растущей популярностью “рельсовых” web-фреймворков и как результат повышеным интересом к GRails.

Удивило, что организаторы опроса добавили в список языков Visual Basic, и ещё больше удивило что почти 5% отпрошенных отдали ему свои голоса. Куда катится этот мир!

Среди предложенных пользователями вариантов мелькали Scala, Scheme, F3, C, E, K, Fortress, Fortan, Beanshell, OCaml, Haskell, Lisp, Pnuts, Smalltalk, Fortress и даже Delphi/Object Pascal вместе C# (мсье знает толк в извратах).
Хорошо, что ещё никто brainf*ck не предложил :)

Догадайтесь за какой голосовал я?

P.S. Помогите найти ссылочки на остальные языки!

Есть в MySQL такая неприятная вещь как "Table is full".
Суть её заключается в том, что в какой-то наступает момент количество данных в таблице превышает 4 гигабайта, и MySQL отказывается выполнять INSERT/UPDATE-запросы.

Ноги этой "бяки" ростут из ограничения на максимальный размер файла на некоторых платформах.
Решается достаточно просто:

где MAX_ROWS - ограничение на количество записей в таблице, AVG_ROW_LENGTH - усредненное количество данный в одной записи (используется только для таблиц с BLOB и TEXT полями).

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

Теперь расскажу почему "table is full" доставляет кучу проблем:

1. При создании таблицы ни один разработчик не указывает MAX_ROWS, потому ошибка возникает на работающих решениях в самый неожиданный момент. (Меня почему-то такое счастье постоянно настигает на выходных)

2. При указании очень большого значения MAX_ROWS, MySQL молча "ложит" на это значение и прописывает "max_rows=4294967295". Таким образом выше 4-х миллиардов записей все-равно не прыгнешь.

3. Решение с проблемы с помошью PARTITIONS работает только на MySQL >= 5.1

4. И как вы думаете сколько времени выполняется указанный выше ALTER TABLE на 4 Гб данных? А сервис все это время находится в состоянии, близкому к коме.

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

Около полугода назад я впервые познакомился с Groovy - динамическим языком для платформы Java.
Он включает разнообразный syntax-sugar (как бы так правильно перевести?) из Python, Ruby, Smalltalk но при этом использует всю мощь JRE и близкий к Java синтаксис.
Вариантов для использоавния такого чуда техники масса: от написания рабочих простеньких утилит и shell-скриптов, до продуктивной разработки web-приложений, тест-кейсов, и сценариев сборки.
Кстати для последних двух задач у Groovy есть встроенные средства: поддержка Ant и JUnit на уровне языка.
Т.к. Groovy компилируется в .class - файлы, то связать поделки на Groovy с Java-программой труда не составляет.
Таким образом проект может быть запрототипирован на Groovy, а потом, при необходимости, понемногу заменять его Java-кодом.

Программа HelloWorld на Groovy будет выглядеть так:

Компиляция

На выходе получаем Hello.class
Запуск

Т.к. в динамических языках фаза компиляции часто опускается, достаточно просто

По аналогии с Python у Groovy есть графическая (groovyConsole) и текстовая (groovysh) консоль.
Ввод команд в консоль необходимо завершать вызовом команды "go".
Также достаточно интересной мне кажется команда "inspect" - открывает Groovy Object Browser на последней выполненой операции - такая себе минимальная IDE.

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

или ещё веселее

И под конец хотелось бы добавить о возможности доступа к членам класса а-ля JavaBeans (вылетело из головы название термина) и передаче значений параметров в конструктор.

Для "затравки" приведу ещё ссылку на статью "GUI in IronPython, Groovy and JRuby", предлагается построить простенький GUI на 3х скриптовых языках, а также ссылку на колонку "Practically Groovy" на сайте IBM.

Для тех кто-то заметил, что несколько дней блог был "Under construction..." приношу свои извинения.
Дело в том, что этот ресурс долгое время работал на виртуальной UML машине, предоставляемой небезизветсным Максом Тульевым. Но на прошлой неделе всей этой системе пришел долгожданный пи конец.
Собственно вялый с моей стороны поиск нового хостинга и стал причиной столь длительного downtime-а.
За новый хостинг хочу поблагодарить магазин Komod в лице Димы Паленкова.

Сегодня утром был искренне поражен узнав что в Java есть метки.
Да-да, именно те самые метки какие есть в других языках и на какие можно "делать goto".
К моей огромной радости оказалось, что ненавистного оператора goto все-таки в Java нет.
Но есть возможность выполнить continue или break с указанием метки.
continue <label> - это безусловный переход к началу блока (почти goto).
break <label> - это выход из блока кода помеченного меткой.
Практичных применений этому я пока не нашел но подозреваю, что можно использовать например выхода из набора вложенных циклов:

PLAIN TEXT
JAVA:

public class Test {
  public static void main(String[] argv) {
    lab1: for (int i=0; i<10; i++) {
      for (int j=0; j<10; j++) {
        if (j>=5 &amp;&amp; i>5)
          break lab1;
        System.out.println(i + " / " + j);
    }
  }
}

}

Хочу рассказать об одной достаточно важной особенности SQL-оптимизатора MySQL.
Предположим в таблице почти 390 миллионов (389239897) записей.

Обычный запрос, выбирающий 10 записей за октябрь 2006 г.

Обращаем внимаени на значения:
key: i_c_time
rows: 89221170

Такой же запрос, но без указания LIMIT:

key: NULL
rows: 389239897

Видно что разница в том, что во втором запросе не используется индекс по полю c_time (key:NULL)
Следовательно происходит полное сканирование таблицы.

Насильно указываем использовать индекс по c_time:

Получаем заветные
key: i_c_time
rows: 89221170

Выясняем каким образом LIMIT влияет на использование индексов в запросах.

Указываем в LIMIT число, меньшее чем количество записей в таблице

Получаем заветные
key: i_c_time
rows: 89221170

Указываем в LIMIT число равное количеству записей в таблице:

Имеем
key: NULL
rows: 389239897

И аналогичный запрос с указанием LIMIT большим чем записей в таблице

И аналогичный результат
key: NULL
rows: 389239897
т.е. полное сканирование всей таблицы

Следовательно при указании значения LIMIT >= количества записей,
оптимизатор MySQL выполняет полное сканирования таблицы.

Подбирая параметры, я пришел к том, что такое поведение наблюдается
только в случае если ожидаемое число строк превышает 20% от общего числа строк.

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

За неименением свободного времени я не стал проводить тесты,
указывая в LIMIT диапазоны значений (например LIMIT 20000,30000),
но что-то мне подсказывает что ситуация будет аналогичная.

Мы все уже привыкли к тому что кредитные карты прочно вошли в нашу жизнь. До сегодняшнего дня я относился к классу людей, которые верили в то, что кредитная карта намного лучше и удобнее морально устаревшей налички. Сегодня - я перестал относится к этому классу. Сейчас попробую объяснить свою точку зрения.
Сегодня я созрел на существенную покупку. Решил немного обновить свой парк элетроники. Я зашел в City.com - местный супермаркет электроники, выбрал "обновочки" на круглую сумму и смело пошел на кассы.
Действие стандартные: удостоверение личности, кредитка - миловидной кассирше немного провинциального вида. Смелое движение картой по разъему терминала - и ожидание чека... В этот момент второй кассирше приспичило поговорить по телефону и она подняла трубку.
- Куда ты, - прикрикнула на нее первая
- Ой, а ты карточку проводишь, - невинно захлопала ресницами вторая.
Из терминала выползла бумажка с надписью: "запрещено"
- А там был модем, - спокойно отшутился я, зная основные свойства транзакций.
- Ага, - ответила она.
Моему удивлению не было предела, когда из терминала вылезла вторая бумажа с надписью: "недостаточно средств". (Как! Ведь я проверял ее перед тем, как войти в магазин...)
Началось самое забавное (в подробностях описывать не буду, уж очень длинная "пьесса" получится - больше часа с антрактом). Позвонили в банк - владелец карточки - транзакция прошла (уже что-то). В банке - получателе (банк - влделец терминала) сообщили, что транзакция неуспешна. (Вот в этом месте я начал действительно сильно нервничать).
Нет, деньги мне вернут - пообещали в обоих банках, но через 30 дней, когда транзакция будет опровергнута документально банком-получателем. Мне от этого легче не стало. Еще пол часа давления на агентов кол-центра, и они соизволили оформить запрос в виде факса на банк-получатель.
Деньги мне вернут не через 30 дней, а через 5, но все равно - мой подарок на новый год сорвался, и настроение крепко подпортилось.
P.S. Как же хорошо, что на карточке остались деньги "на жизнь". Я себе не представляю, что бы я делал, если бы снял _всю_ сумму.

Вот проходит последний рабочий день уходящего 2006 года.
Хотя те, кто знает где и как я работаю наверное пошутят а-ля "Твой последний рабочий день года закончится 31 декабря в 23:59" :)
А вообще эта заметка о моих финансово-проффесиональных планах на 2007-й.
Итак

1. Получить сертификат о праве собственности на свою новую квартиру
2. Забрать диплом с университета (вроде должны 10 лет хранить, но рисковать не стоит)
3. Получить военный билет (пора бы уже эти всерьез заняться)
4. Повысить свой доход как минимум в 2 раза (а лучше в 3 :))
5. Сделать ремонт в новой квартире и поселить туда квартирантов
6. Отдать долги за всю ту же квартиру
7. Нормально изучить J2EE ("нормально" != "поделки на коленках") и внедрить его в компании
8. Заказать большой книжный стелаж на всю стену (количество Оксаниных книг на подоконнике растет экспотенциально)
9. В январе-феврале сьездить покататься на лыжах (Закопане, Буковель или на худой конец Славское)
10. Сделать то, что забыл написать в списке выше...

Писать о планах личного характера не писал нарочно - на то они и "личные" ;)

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

Пока же я ищу причины такого феномена, расскажу о выходе новой разработки от Google - Google Patent Search.
Создатели обещают поиск среди 7 миллионов патентов Американского патентного бюро собранные в период с 1790 по 2006 г.г.
С одной стороны достаточно интересная развлекуха, и возможность расширить кругозор исследуя патенты на скейтборд или солнцезачитные очки.
С другой же стороны возможность поиска патентированности неких собственных идей. А-ля "А не запатентовал ли кто-то это до меня?".

Ещё довольно интересные патенты в области разработки ПО можно найти, задав в качестве строки поиска термин из ловаря разработчика.

Примеры:

Exception handling in java computing environments- Sun Microsystems Inc.

System and methodology providing compiler-assisted refactoring - Borland Corp.

Java C++ proxy objects - Hewlet-Packard

Type checking in java computing environments - Sun Microsystems Inc.

Flattening complex data structures in Java/Javascript objects - IBM
Вообщем читать-не-перечитать.
Да и применений такому поиску думаю можно найти побольше...