exceed_er | Entries tagged with programming

Вообще-то для этого много инструментов, и iMacro у меня давно болталось в FireFox, но я что-то никогда им не пользовался.
А тут у меня была задача заполнить 100 юзеров в одну дурацкую форму.

Открываем iMacro, нажимаем Record, заполняем форму, нажимаем Stop, получаем скрипт:
( Read more... )

Current Mood: accomplished
Current Location: Toronto
Current Music: Lil Wayne - Lollipop (feat. Static Major)

Хорошая цитата:

"...its a sign that you are suffering from a bout of "frameworkitisis" or "architectitisis", painful conditions that affect groups more than individuals and are best detected early and treated by halving the schedule for the first prototype."
в переводе
"... это признак того, что вы страдаете от "фреймвокитии" или "архитектии": болезни, которая поражает группы чаще чем индивидов, и лучше всего лечится сокращением выделенного времени для первого прототипа вполовину".

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

Сегодня после разговора с товарищем об одной небольшой проблеме, я немного погуглил на тему того, что ему сказал. И, как ни странно, обнаружил интересную вещь. Я всегда считал, что если Java "съела" системную память себе под heap, она уже её никогда не отдаст, пока процесс не закончится. Это как бы стандартное поведение Жавы и все с этим примирились. Оказалось, что не совсем так. Стандартные установки 1.6 HotSpot JVM говорят, что если после работы GC свободно 70% heap, то тогда можно отдать системе столько памяти, чтобы осталось 40% heap свободными¹. Такая ситуация встречается весьма редко в жизни. Так что если вам действительно нужно запустить Java процесс c редкими пиками использования памяти, и даже факт того, что физически незанятый heap будет слит на диск по pagination и не будет мешать другим процессам, не помогает, то вот решение, которое я только что проверил и отлично сработало на моей IntelliJ IDEA с загрузкой-выгрузкой огромного (200мб) проекта:

-XX:NewRatio=2 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30

(читать про флаги тут)

[1]больше информации о проблеме и решениях на Сане

UPD: поработал с этими установками в IntelliJ IDEA 2 дня, не выключая. В конце концов началось странное поведение: то говорит что памяти не хватает и просить увеличить -Xmx, хотя там еще 300 мегабайт. То подвисает на минуту-другую неожиданно. Обычно я не закрываю IDEA неделями, и без проблем. Так что, в общем, обращаться надо с осторожностью.

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

jdevelop на эту тему, и на всякий случай решил у себя перепостить.
Сначала соответствие терминологии:
замыкание = closure
продолжение = continuation
примесь = mixin
( Read more... )

С появлением регэкспов в JDK 1.4 стало возможным делать много интересных трюков. Всего несколько строк, например, делают из

public static void Main() {
  System.out.println("Exceeder's blog");
}

вот это:

public static void Main() {
  System.out.println("Exceeder's blog");
}

( Read more... )

Current Mood: energetic

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

В MS SQL есть временами удобный тип - GUID. В С# же, в системной библиотеке, по причине тех же удобств, есть структура Guid. Их сходство невероятно - формат, 128-битовость, свойства случайности генерируемых идентификаторов... Внимательный взгляд внутрь С# только подверждает: тип SqlGuid, возвращаемый из драйвера MS SQL, унаследован от System.Guid. Так что, можно брать "SELECT myguid FROM atable ORDER BY myguid ASC", и спокойно пользоваться резульататами, мастерски оперируя до-диезом? Нам ведь кажется совершенно нормальным, что myguid_i.CompareTo(myguid_i+1) будет всегда меньше нуля? Ибо MS SQL отсортировал их по возрастающей, таким образом в каждой предыдущей клеточке результата Гуид будет меньше последующей?.. Ага! Вот вы и попались.
Правильный ответ: иногда. Иногда будет, иногда не будет. Потому что Guid.CompareTo() сравнивает их как 128-битовые числа. А MS SQL считает последние 48(!) бит единственно(!) важными для сравнения... Не верите?

Зато пришлось, ломая глаза о дебри Гуидной кракозябры, сидеть с распечатками, и, чуствуя себя Франкенштейном Кобола 50-х, выискивать неправильно пробитую краточку. А потом, путем сложных логических вычислений, из дебрей же трансформацинного алгоритма с несколькими уровнями сложности, понять ЧТО же там не работает, и КАК оно на самом деле работает. Потом проверить документацию, и прочитать ее, но совсем не в том месте, в котором я даже теоретически мог бы ее найти. Ибо расписаны эти отличия в SqlGuid.CompareTo подсказке, а все алгоритмы работают на уровень выше, независимо от драйверов конкретных баз данных, и пользуются универсальным Guid'ом. Помощь для которого я внимательно прочтитал много раз... Ыыых.

Но проблема теперь даже не в этом. Достаточно ли уникальны последние 48 бит, чтобы полагаться на однозначность сортировок больших наборов данных в будущем? Ибо ж, блин, оно и QA скорее всего пройдет, а вот когда у клиента будет очерендная пара миллионов записей, вот тут и ё... упадет моя программка. Мда. И че теперь? Сосать всё в память, ибо MS SQL сортировке не обучен? В непонятках я... Спасибо за внимание, крик души просто.

Current Mood: crazy

Мишель открыла глаза. Часы на тумбочке показывали пять утра, вчерашний перелет из Европы сбил ритм сна. Вечером ее хватило только на то, чтобы умыться и влезть в чистое белье и футболку, укрылась она покрывалом и спала прямо на матрасе. Лежать больше не было смысла, Мишель села на кровать и посмотрела через огромное окно с высоты тридцатого этажа на утренний город в предрассветных сумерках. Уходящие в перспективу ровные клетки освещения главных улиц, острова небоскребов, урбанизация а-ля Америка. Она встала и прошлась по еще неуютной и необжитой квартире. Хотя вся мебель была собрана и стояла на своих местах, а кухня была уже почти закончена, остальные вещи стояли в ящиках. Мишель села за письменный стол в кабинете, провела рукой по сенсорам, средняя панель почти бесшумно поднялась и раскрылась тремя мониторами. Под ней освободился доступ к клавиатуре и скетч-пэдам. Биоидентификатор загрузил рабочий профиль. Сначала она кликнула на иконку с кофе, потом набрала адрес си-форума своей группы. В это время там никого не было, но пробежаться глазами по заголовкам сообщений помогало почуствовать себя чуть более комфортно, не так одиноко в пустой квартире. Последний пост был всего полчаса назад, Дэн оставил какую-то трехмерную аллюзию на комиксы начала двадцатого века и пожелал спокойной ночи. Мишель улыбнулась и потянулась. К столу тихонько подкатился столик со свежесвареным кофе и сливками, за окном начинало светать, начинался новый день.
( Read more... )

Как обычно, я не собираюсь писать законченную статью, а скорее общие мысли и кое-какие находки по интернету. На ковыряния меня натолкнули сумбурные впечатления от LOP a-la IDEA.

За свою недолгую пятнадцатилетнюю карьеру я сам разработал три несложных языка (DSL as in Domain-Specific Language, конечно, за такие daunting вещи как общий язык программирования я не возьмусь - у меня бороды нет) и еще не участвовал в проекте, где бы в том или ином виде такие языки не появлялись. Что еще сложнее, так это определить, где же заканчиваются данные и начинается язык. Я для себя определяю три степени "языковатости" конструкций, используемых в API.
( Read more... )

Current Mood: суббота, 3 ночи, а я пишу о чем?

Сегодня было немного времени - скачал новую, самую последнюю версию (160ю) джет-брейновского MPS. Заодно уже поставил на бету 5й IDEA. Прошел туториал по созданию своего языка программирования. Особенно это было любопытно, потому что свои языки и интерпретаторы-трансляторы к ним я уже писал. ( Несколько замечаний и соображений. )

Current Mood: наработался
Current Music: щас в машине будет

С удовольствием прочитал вот эту статью: http://www.joelonsoftware.com/articles/APIWar.html
(кстати, ППИ = прикладной программный интерфейс = API. Не знаю, пользуются ли этой аббревиатурой еще, вообще не завидую переводчикам программерских материалов)

Хотя статья обьясняет, почему и как Майкрософт проиграл одну весьма важную для него войну, она отнюдь не анти-майкрософт. Скорее она выражает взвешенную точку зрения программиста, который выбирает инструменты для программы, которой работать следующие 5-10 лет. Я не нашел места, где бы я был не согласен с автором. Плюс, отличное чувство юмора и много мест, где я ржал.

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

"В начале 90х многие из нас думали, что большая битва будет между процедурным и ОО-программированием, и мы думали что ОО резко улучшит продуктивность. Я тоже так думал. Многие люди все еще так думают. Оказалось, что мы не правы. ООП - очень удобный прикол, но это не то что было обещано. Настоящее значительное улучшение продуктивности исходит от языков, которые автоматически управляют памятью для вас." (VB, Java, C#, Lisp..)

Из статьи становится предельно ясно, почему Intenet Explorer уже несколько лет не развивается (и не будет), что происходит с C# и почему гораздо больше программ на C# для веба а компании не спешат переводить свои существующие программы на .НЕТ.

В конце статьи есть немного рекламы софта, который автор разрабатывал, и я уже совсем ржал на вот этом скриншоте:
http://www.fogcreek.com/FogBUGZ/40tour/06.html
Он в деталях показывает путь ошибки, найденной клиентом через менеджеров и программеров в новый релиз.

"It is funny how people think that the important thing about exceptions is handling them. That is not the important thing about exceptions. In a well-written application there's a ratio of ten to one, in my opinion, of try-finally to try-catch."
Anders Hejlsberg

+1.

[...] and I can't tell you how many times I've seen this—they say, "try, da da da da da, catch curly curly."[...]

- YEP.

"Five minutes Turkish!
Hold on....they were 2 minutes 5 minutes ago....."

Following

ivan_ghandhi's posting, I feel like joining the gang.

1. How did you begin programming in Java? Did you choose it or did Java "happen" to you because of your educational or work environment? If you were starting today, would you choose Java again?

My first Java experience was in 97, I was doing some kind of feature-rich internet applet with tons of graphis. It was for a "Sparkasse"'s web appearance, but I was doing it as a generic template for such things. Today I would definitely do it with Flash, but back then Java 1.1 was a better choice. My first experience didn't even scratch Java language features, it was more of annoyance, since my primary work was a CMS for banks and financial sector - aligned towards web and touchscreened public terminals. It was written in Delphi, which is a very powerful language, with many metadata features mostly untouched by developers (yes, it has full reflection the way Java has, but no GC and no bytecode). I miss some of its features in Java. Java is still bad for what I like to do most: computer graphics programming. Mostly because GC can't run in background without distorting the dynamics of the graphics engine. But it makes up on the backend - big time. I would choose Java for any kind of server-side development anytime.
( 9 more Q&A's )

Писал я тут в одном форуме как бы на злобу дня:

«Вообще в 40-50 лет топтать клавиатуру в девелоперском окне уже не фильтикультяпно вроде. Разве что это хобби. Однако, есть уйма альтернатив для "выросших" программистов. Самая простая - менеджмент проектов и вверх. Другой вариант - консультант по определенной технологии, на которой собаку сьел. Желательно чтобы она пользовалась небольшим постоянным споросом, и таких как ты была дюжина-другая в мире. Третий - преподавать в универ. Это самые простые, лежащие на поверхности, теперь уже стандартные варианты. Есть еще архитекторы систем - системный архитекторы.
Если ни на один из них не дотягиваешь профессионально, наверно лучше выучить что-то еще. 40-летний хакер (в хорошем, первоначальном смысле) звучит уже несолидно, хотя встречается сплошь и рядом...»

и тут призадумался. Вроде как вещи стали меняться. То есть сейчас все несколько не так. Раньше 35 был уже почти предел для акшн-программеров - просто гибкости ума не хватало. Постоянные программерские революции превращали годы написанного кода в
мусор. Нужно было полностью перестраивать мышление, адаптироваться к совершенно новому миру и начинать с нуля. И с возрастом обе позиции сдают - ну не хочется начинать с 0 да еще и похерив свой багаж знаний. Было конечно несколько исключений, например Кобол. Но умение рисовать точки через ассемблер в бейсике на VGA мониторе можно было скрутить в трубочку.
Сейчас революции продолжаются, но они больше не сравнивают все построенное с фундаментом. Развились новые методологии - тот же рефакторинг, которые помогают мигрировать код из одной идеологии в другую. Плюс, такие вещи как реляционные алгебры, теория IR
(information retrieval), различное линейное программирование и оптимизации, и т.д. и т.п. - они уже не пропадут. Это универсальные знания, на них всегда будет спрос, как на профессионалов в сопромате в архитектуре. Раньше просто в программировании не было такой глубины теорий, что ли. А там, где была - люди и с 70х до сих пор при деле. Взять те же сетевые протоколы.

В общем, не всё так плохо у программистов :) Но жаловаться мы любим. Ибо, как известно, карта слезу любит.

Задача возникает, когда Апач уже настроен на openssl c ключом и подписанным RSA сертификатом, а надо чтобы Томкат тоже этим же сертификатом пользовался. Применимо от для веб сервисов на отдельном порту до желания полной замены Апача томкатовским встроенным HTTP Server'ом.
Это типа хозяйке на заметку :)
( Read more... )

Хотя, как ловко заметила одна моя очень хорошая подруга, я всё время программирую в жизни, многие программерские коцепции весьма применимы. К примеру, взять проблему самоидентификации. Люди постоянно бьются над вопросом "кто я" и ищут способ себя уникально идентифицировать. Вот чтобы во всём мире на нашлось ни одной копии и никогда ни с кем не перепутаться. Как ни странно, с этой проблемой повседневно сталкиваются программисты и даже придумали "глобальный уникальный идентификатор", или ГУИД, для обьектов. Проблема в том, что (а) он жутко длинно непрактичный и (б) гарантии что он никогда в мире нигде не повторится - нет. Есть только статистическая вероятность. Куда проще иметь идентификатор в зависимости от окружающей тебя действительности, т.е. от контекста программы. Так что я советую всем, ищущим себя, поверить нашему программистскому опыту и не рефлексировать по поводу изменения своей identity в зависимости от обстановки. Ваша выживаемость как обьекта только увеличится ;-)

Зашёл в Chapters, взял книжку по Джаве. Называется "Жаба в Гараже". Прочитал про как написать читалку RSS feed'a. Сразу за этим узнал, как сделать хороший стейк. И как к этому стейку смешать настоящий Манхэттен. Оказывается, автор бомбил в Нью-Йорке барменом. Но в Жабе шарит, вопросов нет. Вообще прикольно написал, жаль, что почти все это знаю, если не считать кулинарную часть. Но тренд приветствую. Вообще, раз скучные книги не идут, люди опять начинают писать с оттягом. Как когда-то моя первая книга по С была синяя, трех авторов с хорошим чуством юмора. А потом пошли перепечатки документаций по 1000 страниц... хорошая книга толстой не бывает¹, в отличие от людей :)

Рассказ

mindsurferа довёл бы меня до слёз, если бы я его знал чуть меньше лично. Зато ему это вполне удается вживую :) Прямо жаль, что мы с ним чаты забросили.

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

Стыдно сказать, а также пришло время воспользоваться CVS под виндоуз. К сожалению, французская черепашка (Tortoise) что-то криво встала и не дает мне вычекивать проекты через меню Эксплорера. Хоть на Линух переходи (не могу, если честно).
_______
1) Войну и Мир хорошей книгой не считаю.

Seprataion of concerns design principle

separation of interface and implementation - это, впрочем, понятно, пользуемся, но есть ли четкие правила что и как интерфизировать?

component-oriented programming - красивые слова, где за этим каждый понимает что-то своё, или всё же есть общий принцип?

inversion of control - "драстуй, Весна" :)

В разных комбинациях об этом кричат на каждом углу. Даже я сам уже умею об этом что-то умное ввернуть. Но от этого всё время веет нео-маркетингом якобы бесплатных открытых систем. Хочу технарский малословный дельный набор определений и примеров. Желательно без АОР и как можно более на пальцах. Попробую провикипедить.
( Read more... )

(давно вот тут обещаное продолжение)

...под нею красовался кусок фанеры с надписью чернилами вкривь и вкось:

                     КОТ НЕ РАБОТАЕТ
                                 Администрация

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

1. Неопределенность удаленного воздействия
Пусть x,y это обьекты классов X и Y соответственно; пусть f - метод класса X и g - метод класса Y. Введем нотацию

x.f ≈> y.g

означающую:
x.f может быть причиной вызова y.g как напрямую, так и опосредовательно, через вызовы других методов.

Во всех ОО языках существует понятие импорта, которое в лучшем случае обьясняет, какие другие классы нужны для работы текущего, но мало что дает при выяснении области воздействия W(x,f) вызова метода x.f:

W(x,f) = {(y.g) | x.f ≈> y.g}

( ... >>> )

2. Бумеранг
Область воздействия может в процессе своего распространения через вызовы методов вернутся на исходный класс:

x.f ≈> x.g

В случае f=g мы имеем тривиальную рекурсию. Даже опытный программист не видит здесь проблемы, хотя именно этот эффект стал причиной огромного количества трудноустраняемых ошибок. Обычно на практике разработчики наивно полагают, что каждый обьект перед вызовом и после завершения каждого метода находится в непротиворечивом (целостном, consistent) состоянии. Однако на момент вызова x.g, который произошел глубоко внутри кода x.f, обьект как раз выглядит случайным образом и может как угодно противоречить логике x.g. По крайней мере, следует различать между методами, которые требуют целостности обьекта, и такими, которым все равно.( ... >>> )

Current Mood: accomplished
Current Music: тишина Торонтской ночи, редко проезжающие машины, открытое окно

А я стал такой booooring. Бееее...

Надо чего-нибудь нахулиганить. Как настроение будет. Я сейчас увлёкся чего-то теоретическими разработками в самом сердце программирования: завис на статье[нем., 400кБ] одного из современных светил информатики Манфреда Броя про ООП. Что оно устарело и вообще никуда ни годится. Прямо медитирую над ней уже несколько дней.

ООП не предоставляет подходящего определения компоненты как базового элемента софтверной архитектуры

ООП не определяет композиции классов

Модель выполнения программ в ООП - последовательная, 1967г выпуска, что никак не помогает в распределенных и мультипроцессорных архитектурах

ООП не определяет аспекты поведения интерфейсов, только в лучшем случае специфицирует методы

Наследование имплементаций нарушает принцип секретности частных данных и приводит к недетерминизму

О как. Позже больше расскажу :) Пора на ланч.

Только что закончилась конференция и, я думаю, с точки зрения перспектив в программировании и в мире Java, она открыла намного больше нового, чем в предыдущие несколько лет. Почти все концептуально новые вещи были построены на базе Tiger (в простонародии - JDK 1.5, с точки зрения маректинга - J2SE 5.0). Собственно, концептуально новым стало очень широкое использование метадаты (видимо, это избитое у архитекторов слово, теперь прочно станет ассоциироваться со всякими public void @Ingect ... и придется изобретать что-то новое). В комбинации с generics - концепция генерализации типов данных - это открывает много новых путей, чтобы отслеживать и понимать связи между классами и обьектами. Не удивительно, что новый EJB 3.0 полностью базируется на этих двух технологиях, избавляясь таким образом от XML-дескрипторов.

Отдельно стоит упомянуть о двух сессиях, на которых эти самые EJB 3.0 стали доступны простым программерам. Учитывая, что по своей сути они портят малину JDO, а так же создают много неприятностей BEA и другим производителям J2EE серверов, политики на сессиях было так же много как и технической части. Конечно же, это большой шаг вперед. Но уже по дискуссии на BOF, когда известные архитекотры, за которыми стоят сети банков и страховых, задавали всякие конкретные вопросы, было понятно что слишком много проблем осталось открытыми, и что EJB 4.0 не за горами. Ну то есть сама идея очень прогрессивна, гораздо большее количество людей перейдут на "полноценный" J2EE, но это не конец :)
( Read more... )