3-х минутное видео, представленное в блоге LinkedIn, рассказывает Success Story некоего мнимого владельца бизнеса, которому LinkedIn помог в поиске партнеров и развитии собственного дела.
Очень просто и доходчиво – если сжать длительность вдвое – можно и как рекламу на ТВ пускать.

P.S. Кстати за свое текущее место работы я тоже должен благодарить LinkedIn.

Начиная с первых “бэт” версии 1.6 в Groovy были добавлены 2 встроенные аннотации (да-да! Groovy наконец-то полностью поддержирживает все возможности Java5!) : groovy.beans.Bindable и groovy.beans.Vetoable

Обе аннотации содержат в себе функионал который призван заменить стандартные Java-интерфейсы java.beans.PropertyChangeListener и java.beans.VetoableChangeListener и избавить разработчика от обилия классов-слушателей (listeners) и декларации дополнительных интерфейсов для бина.

Об этих нововведениях и их назначении было напечатано/перепечатано в каждом обзоре новых “фич” версии 1.6, но при этом нигде не встречалось описания как же все-таки “повесить” свой обработчик событий (listener).

Немного поковырявшись в исходниках Groovy удалось узнать такое: [Далее...]

Цитата:

Работаю в вебконторе, сижу смотрю на девочку-программиста напротив -
она смотрит на монитор и бьёт кулаками по клавиатуре. Нежно так, но кулаками :)
- Че, грю, делаешь?! Альтернативные методы разработок?
- Да грит не, я пароль на фтп для пользователей генерирую %)
Источник: http://bash.org.ru/quote/393171

Самое смешное в том, что до недавнего времени я делал точно также. Пока сегодня не прийшлось сгенерировать порядка 50 паролей подряд.
Выручил меня такой вот примитивный генератор паролей:

base64 /dev/urandom | head -n1 -c6

Когда-то, во время моего доклада на киевской встрече developers.org.ua, кто-то (кажется Алексей Колупаев) спросил где на реальных действующих проектах используется Groovy и Grails.
Первое, что я ответил – это LinkedIn. Но вот конкретнее рассказать, где там Grails а где Java, в силу непричастности к разработке этой соц-сети – не смог.

Теперь же инженеры LinkedIn сами поведали нам “где”, “как” и главное “зачем” у них используется Grails. Смотрим презентацию: [Далее...]

Недавно впервые удалось попробовать использовать JavaScript-библиотеку jQuery.

Из того, что понравилось сразу – это возможность выполнять JavaScript-код не по событию полной загрузки страницы (window.onLoad), а сразу после загрузки и инициализации DOM-дерева. Т.е. можно уже выполнять манипуляции с DOM-деревом не дожидаясь загрузки стилей, изображений и остальных медиа-компонентов.

В jQuery реализуется это 2-мя способами:

$(document).ready(function(){...})

и в сокращенной нотации

$((function(){...})

Но так как я являюсь давним пользователем prototype.js  – сразу же захотелось такую же возможность и в нем. Как оказалось в версии 1.6 она уже есть, и использовать её можно таким образом:

document.observe('dom:loaded', function(){ ... })

или

Event.observe(document, 'dom:loaded', function(){ ... })

Работоспособность проверял на Prototype 1.6.0.2 в Firefox3, Internet Explorer 6 и Safari (Win+Mac).

“Словил” сегодня пренеприятнейший баг, который стоил мне более часа потерянного времени.

Выполняем в консольном mysql-клиенте такой запрос:
SELECT SQL_CALC_FOUND_ROWS FROM tablename LIMIT 5;

Получем resultset из 5ти результатов (предполагается, что в таблице tablename больше 5ти записей)

Теперь в этом же соединении выполняем:
SELECT FOUND_ROWS();
Получаем значение, равное количеству строк в tablename – ничего сверхъестественного, все как и ожидалось.

Самое интересное начинается если повторить выполнить эти SQL-запросы из PHP-скрипта (при определенных условиях, но о оних ниже) – второй запрос будет всегда возвращать 0.

Причиной всему – ошибка в модуле php_mysql.so (BUG#33021), которая наблюдается при включенной опции
mysql.trace_mode=true

Дабы не поулчить подобную неприятность в своих проектах рекомендую пока установить mysql.trace_mode в false.

При тестировании использовался PHP 5.2.1 и с модулем mysql client API 5.1.16-beta.

В Groovy подключить дополнительные Java-библиотеки и классы можно 3-мя способами:

1. Дописыванием пути к jar-у или директории с классами в глобальную переменную CLASSPATH
2. Указанием значение параметра -classpath (он же -cp) при запуске groovy, groovysh, и тд.
3. Размещением необходимых jar-ов в директории ~/.groovy/lib

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

Вспомнив про черновик заметки о ClassLoader-ах, которую Юра все никак не соберется дописать и опубликовать,  получилось что-то вроде:

Простой прием, демонстрирующий определение местополжения класса и загрузку дополнительных JAR-ов

[java]

def codebase = this.getClass().getProtectionDomain().getCodeSource().getLocation()
def f = new File(codebase as String)

def url = new URL(f.getParent()+"/commons-lang-2.3.jar")

this.getClass().getClassLoader().getRootLoader().addURL(url)

Class au = Class.forName("org.apache.commons.lang.StringUtils")

assert au.isEmpty(null) && au.isEmpty("")

[/java]

P.S. Кстати запускать groovy-скрипт в UNIX-среде можно точно так же, как и sh, perl, php, python скрипты – указанием в первой строке:
#!/usr/bin/env groovy

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

Т.е. если раньше писал что-то вроде:
$ php -r 'echo strlen("0bed4ce7b082e0f1ca05")."\n";'

или

echo "0bed4ce7b082e0f1ca05" | wc -c

то теперь первое, что приходит в голову, это:

groovy -e 'println "0bed4ce7b082e0f1ca05".size()'

P.S. Пример, конечно же, получился не очень показательный, но жизненный – проверял длину идентификатора для выделения для него поля в БД.

P.S.S. Это только у меня echo "0bed4ce7b082e0f1ca05" | wc -c выдает 21, в то время как PHP и Groovy – 20?

Вместе с выходом беты Java Development Kit 6u10, Sun анонсировали и выход вспомогательной, но IMHO очень полезной JavaScript-библиотеки  Java Deployment Toolkit.

Назначение библиотеки – сделать развертывание и запуск Java-приложений в среде Web (апплетов, WebStart-приложений) более простой и комфортной.
При этом библиотека берет на себя задачи по определению установленных JRE, проверки соответствия их версий минимальным требуемым приложением, установке обновлений (если необходимо) и конечно же кроссбраузерного добавления обьектов на страницу.
Получается такой себе аналог SWFObject для Java.

Использовать Java Deployment Toolkit  очень просто – достаточно подключить на web-страницу единственный JavaScript-файл:
[javascript]<script src=”http://java.com/js/deployJava.js”></script>[/javascript]

Пример добавления аплета на страницу будет выглядеть так:

deployJava.runApplet({codebase:"http://voituk.kiev.ua/demo/",
  archive:"TumbleItemProject.jar", code:"components/TumbleItem.class",
  width:"600", Height:"95"},
{maxwidth:120, nimgs:17, offset:-57, img:"images/tumble"}, "1.5")

где первый параметр метода runApplet() – параметры тэга <APPLET>,
второй – параметры, передаваемые самому апплету (значения <PARAM>),
третий – минимальная версия JRE необходимая для запуска апплета.

Что  по cути отличается от использования старого доброго тега <APPLET> только формой нотации (JSON вместо HTML).

При этом, при попытке зайти на страницу с апплетом с помощью браузера, без установленного (или с устаревшим) Java Plugin, будет предложено установить последнюю версию оного.

Не все веб приложения одинаковые: одни большие, даже монстроидные: работают на кластерах веб-серверов и общаются с ордами баз данных и сервисов. Другие поменьше и поскромнее – работают, как правило на одном выделенном сервере, иногда ненавязчиво беседуя с сервером баз данных. Есть еще и третьи – совсем маленькие странички, которые выполняют очень узкий круг задач и обслуживают небольшое количество пользователей: они зачастую запущены на той же машине что и СУБД.

В этой заметке я уделю внимание третьему типу приложений – совсем маленьким системам. Их функционал ограничен небольшим набором вспомогательных функций, которые, к примеру, могут поддерживать основное приложение. Давайте на секунду представим, что нам потребовалось написать такое приложение. Какие будут первые действия? Конечно, установка Tomcat и MySQL. Вам не кажется неправильным, что ради запуска пары сервлетов вам нужно установить две достаточно больших и тяжеловесных системы? Что уж говорить о поставке такого “монстра” пользователям.
[Далее...]