Dec 26, 2008
Java to Python source code transformation
Recently yava2python project was released. The core is based on java2tcl transformations. Test Java files included in the package give better performance than java2python, although the latter may better transform some other code.
Dec 14, 2008
Java to Tcl source code transformation - java2tcl
I have developed a Java to Tcl source code translator in TXL. As an object orientation XOTcl was choosen.
The results of this language source transformation project are not bad. There are a lot of simplifications in the translator, so in the most case it will require manual updates for the generated code.
In the future it is possible to add info about Java classes into translation process to let the translator know how to correctly transform invokes of third party classes.
But most probably the project will be stopped at the current state, since it wass a leisure time project and no commercial support was expected.
The results of this language source transformation project are not bad. There are a lot of simplifications in the translator, so in the most case it will require manual updates for the generated code.
In the future it is possible to add info about Java classes into translation process to let the translator know how to correctly transform invokes of third party classes.
But most probably the project will be stopped at the current state, since it wass a leisure time project and no commercial support was expected.
Feb 1, 2008
SCRUM
Посетил сегодня тренинг Agile Software Development with SCRUM, проведенный проектом SCRUMguides, при поддержке компании Ciklum и Валидио Украина.
В целом было интересно. Со SCRUM до этого знаком не был, поэтому за 4 часа получил общее представление об этом модном явлении. В целом я так понял это набор практик, уже давно существующих в других методологиях, но названных по другому при agile (я называю: ушлой) разработке.
Больше всего меня поразила идея самоорганизующихся команд (self-managed teams), в которых разработчики сами инициативно ставят себя задачи, расставляют приоритеты, берут на себя ответственность. С трудом представляю себе такую команду. Это наверное такие супер-человеки с опытом работы от 5 лет, очень коммуникабельные, инициативные, с широким мышлением. Но все равно считаю, что нужен человек, который своим взглядом охватывает всю систему целиком и направляет течение проекта.
Почему-то тренеры пытались предоставить типичного проджект-менеджера как личность, которая мешает разработке и дает глупые указания кому чего делать и в результате все проваливается. И только SCRUM master (я про себя назвал его душа компании) по-отечески следит и подсказывает (только когда попросят или ситуация зашла в тупик).
Диаграмма burndown как мне показалось сама по себе не информативна и должна сопровождаться каким-либо прогрессом по затраченному времени и процентам выполнения задачи.
Еще как оказалось, что UML и SRS это уже не модно. Как сказал один мой знакомый, тоже посетивший тренинг: "UML используют стыдливо". Шаблоны документов - это накладно.
По личному опыту я бы отметил, что время потраченое на документирование требований и хоть небольшое, но моделирование архитектуры приложения и ее отображение в UML с лихвой себя окупает позже при развитии проекта.
До этой встречи было желание посетить платный 2-дневный тренинг. Сейчас же желание отпало. Ну разве что цена упадет до 100$-200$. И поскольку это все дело модное, я думаю можно на рынок выйти с продуктом для поддержки коллективной работы в стиле SCRUM ;)
Еще хотелось бы порадоваться за наш город, что такие встречи здесь проводятся.
В целом было интересно. Со SCRUM до этого знаком не был, поэтому за 4 часа получил общее представление об этом модном явлении. В целом я так понял это набор практик, уже давно существующих в других методологиях, но названных по другому при agile (я называю: ушлой) разработке.
Больше всего меня поразила идея самоорганизующихся команд (self-managed teams), в которых разработчики сами инициативно ставят себя задачи, расставляют приоритеты, берут на себя ответственность. С трудом представляю себе такую команду. Это наверное такие супер-человеки с опытом работы от 5 лет, очень коммуникабельные, инициативные, с широким мышлением. Но все равно считаю, что нужен человек, который своим взглядом охватывает всю систему целиком и направляет течение проекта.
Почему-то тренеры пытались предоставить типичного проджект-менеджера как личность, которая мешает разработке и дает глупые указания кому чего делать и в результате все проваливается. И только SCRUM master (я про себя назвал его душа компании) по-отечески следит и подсказывает (только когда попросят или ситуация зашла в тупик).
Диаграмма burndown как мне показалось сама по себе не информативна и должна сопровождаться каким-либо прогрессом по затраченному времени и процентам выполнения задачи.
Еще как оказалось, что UML и SRS это уже не модно. Как сказал один мой знакомый, тоже посетивший тренинг: "UML используют стыдливо". Шаблоны документов - это накладно.
По личному опыту я бы отметил, что время потраченое на документирование требований и хоть небольшое, но моделирование архитектуры приложения и ее отображение в UML с лихвой себя окупает позже при развитии проекта.
До этой встречи было желание посетить платный 2-дневный тренинг. Сейчас же желание отпало. Ну разве что цена упадет до 100$-200$. И поскольку это все дело модное, я думаю можно на рынок выйти с продуктом для поддержки коллективной работы в стиле SCRUM ;)
Еще хотелось бы порадоваться за наш город, что такие встречи здесь проводятся.
Subscribe to:
Posts (Atom)