Есть такой фреймворк iBatis. Судя по названию сначала кажется, что делали его славяни (особенно с учетом н овости на главной странице "Abator Renamed to iBATOR"). Но вот заяление "iBATIS couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the iBATIS Data Mapper over object relational mapping tools." притягивает. И вообще как оказалось замечательный фрэймворк!
среда, 28 мая 2008 г.
Hibernate vs JDBC
JDBC изначально содержит совсем небольшое количество кубиков-понятий для работы с базами данных, что делает его простым в использовании инструментом и в тоже время достаточно гибким оставаясь понятным. Hibernate и прочие ORM (включая JPA) - это в некотором роде макро-абстракция над JDBC. Изначально кажется, что ORM позволяет абстрагироваться от синтаксиса конкретной базы данных и упростить запросы, сократить процесс переноса данных из запроса в домэйн обьекты. Но чем больше я работаю с ORM тем больше понимаю, что абстракция от базы данных на практике мало нужна, разве в простых приложениях. А простота маппинга достигается за счет оверхеадов при работе, сложности с маханизмами каскадирования, дэтачмента обьектов, майнтененсом сессии и в конце-концов выясняется, что временя потраченное на поиск причины сообщения о проблемы с транзиентными записями, попытке приаттачить обьект внутри сессии, с валидацией полей, проблемами ленивой подгрузки обьектов и прочих проблем.. это время равносильно, а то и больше времени которое было бы потрачено на разработку с JDBC + портирование приложения на новую базу (с учетом, что изначально в коде используется шаблон проектирования DAO). ORM привносит обилие новых понятий, сущностей и рычагов, добавляет mutual состояния (а мы знаем, что чем меньше в приложении мутирующих перменных/состояний, тем более стабильно приложении (именно по этому фнкц-языки рулят)), что очевидным образом вытекает во все что я описал в предыдущем предложении. Есть ли смысл?
Есть такой фреймворк iBatis. Судя по названию сначала кажется, что делали его славяни (особенно с учетом н овости на главной странице "Abator Renamed to iBATOR"). Но вот заяление "iBATIS couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the iBATIS Data Mapper over object relational mapping tools." притягивает. И вообще как оказалось замечательный фрэймворк!
Есть такой фреймворк iBatis. Судя по названию сначала кажется, что делали его славяни (особенно с учетом н овости на главной странице "Abator Renamed to iBATOR"). Но вот заяление "iBATIS couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the iBATIS Data Mapper over object relational mapping tools." притягивает. И вообще как оказалось замечательный фрэймворк!
Flash, JavaFX, Silverlight, Flex
В эпоху достаточной конкуренции среди одинаковых веб услуг, появление модного слова AJAX показало, что пользователи хотят видеть веб сайты не просто информативными, но с красивым гуевым интерфейсом. Осознав это, компании, практически одновременно, принялись "первыми" выкидывать на рынок или просто разрабатывать новую технологию которая непременно же должна заменить HTML и сделать internet application'ы не просто Rich, а как я услышал в одном докладе на SUN'вской конференции прямо таки Filthy Rich! И все это под open source. Ну прям таки не жизнь, а мед грядет. За что я люблю веб over обыкновенное приложение (пусть оно хоть трижды filthy like a whore):
1. Любую вэб страницу я могу отмасштабировать (увеличить или уменьшить шрифт).
2. Выключить стили мега дизайнера нахрен.
3. Сохранить отдельную страницу.
4. Поставить ссылку на отдельную страницу.
5. Вернуться на пару страниц назад.
6. Окно можно растянуть или сжать не в ущерб содержимому. При этом браузер все красиво переформатирует.
7. И т.д.
Все это конечно же можно реализовать и плагином, но я уверен, что 90% RIA сайтов делать этого не будут. Короче все это бред и лажа. По крайней мере в том виде в котором оно сейчас есть в виде флэша или ему подобных технологий.
Что я точно не понимаю, так это стратегию компании SUN. Ну ладно, хрен с ними с апплетами. Проипали они это поле битвы. Но почему бы в джава плагин не встроить нативно API для интеграции с DOM и Javascript? Модифицировать DOM дерево страницы браузера вроде бы можно, но я так и не нашел, читая javadoc, способа, как например из java повесить свой java handler для onclick или другого event'а какого-то узла этого DOM дерева. Сдается мне, что все на что хватает интеграции из коробки - удалять/добавлять узлы DOM дерева. Есть сбоку LiveConnect, но во первых он сбоку. А во-вторых что с event'ами сходу не понятно, но вроде как есть надежда. Ну чтож, хрен с ними с евентами, может что-то и получилось бы. НО!! Компания САН уже несколько лет не в состоянии выпустить плагин под 64 битные платформы (с 2004го кажется)... и обещают они выпустить java plugin к 2009г. Какие нахрен апплеты, какие RIA..?
А всего-то. Была бы в джаве вместо всей этой мега-графической мега-херни для создания мега-никому-не-нужных-грязных-апплетов возможность работать с деревом DOM и событиями - небыло бы необходимости в виде костылей GWT (компиляция из ограниченного сабсета Java в Javascript), потому как это java код напрямую бы работал и делал все, что сейчас делается на JS. Те же GWT виджеты и т.д. все бы было, но с отладкой прям в браузере, мониторинг по JMX и прочие прелести разработки и отладки java standlone, но в вебе. Такое чувство, что в сан только и могут языком трепать и евангелистов разбрасывающих дюков по миру катать.
А пока пойду попробую GWT 1.5rc1...
1. Любую вэб страницу я могу отмасштабировать (увеличить или уменьшить шрифт).
2. Выключить стили мега дизайнера нахрен.
3. Сохранить отдельную страницу.
4. Поставить ссылку на отдельную страницу.
5. Вернуться на пару страниц назад.
6. Окно можно растянуть или сжать не в ущерб содержимому. При этом браузер все красиво переформатирует.
7. И т.д.
Все это конечно же можно реализовать и плагином, но я уверен, что 90% RIA сайтов делать этого не будут. Короче все это бред и лажа. По крайней мере в том виде в котором оно сейчас есть в виде флэша или ему подобных технологий.
Что я точно не понимаю, так это стратегию компании SUN. Ну ладно, хрен с ними с апплетами. Проипали они это поле битвы. Но почему бы в джава плагин не встроить нативно API для интеграции с DOM и Javascript? Модифицировать DOM дерево страницы браузера вроде бы можно, но я так и не нашел, читая javadoc, способа, как например из java повесить свой java handler для onclick или другого event'а какого-то узла этого DOM дерева. Сдается мне, что все на что хватает интеграции из коробки - удалять/добавлять узлы DOM дерева. Есть сбоку LiveConnect, но во первых он сбоку. А во-вторых что с event'ами сходу не понятно, но вроде как есть надежда. Ну чтож, хрен с ними с евентами, может что-то и получилось бы. НО!! Компания САН уже несколько лет не в состоянии выпустить плагин под 64 битные платформы (с 2004го кажется)... и обещают они выпустить java plugin к 2009г. Какие нахрен апплеты, какие RIA..?
А всего-то. Была бы в джаве вместо всей этой мега-графической мега-херни для создания мега-никому-не-нужных-грязных-апплетов возможность работать с деревом DOM и событиями - небыло бы необходимости в виде костылей GWT (компиляция из ограниченного сабсета Java в Javascript), потому как это java код напрямую бы работал и делал все, что сейчас делается на JS. Те же GWT виджеты и т.д. все бы было, но с отладкой прям в браузере, мониторинг по JMX и прочие прелести разработки и отладки java standlone, но в вебе. Такое чувство, что в сан только и могут языком трепать и евангелистов разбрасывающих дюков по миру катать.
А пока пойду попробую GWT 1.5rc1...
понедельник, 19 мая 2008 г.
OWFS 2.7p4
Нашел багу в OWFS 2.7p4. Немного криво написанная блокировка приводила к обращению к уже освобожденному участку памяти. Проявлялось через 1сек-5мин (как повезет) при паралелльном обращении к датчикам: owfs выключалась либо молча либо с сообщением функции tsearch из glibc о поврежденном списке. GDB помог не сильно. Valgrind помог весьма - отличная тулзень, давно ей пользуюсь.
Пропатченная версия работает уже 2 часа без проблем. Если до вечера доработает без ошибок напишу в mailing list owfs.
Патч.
P.S. Valgrind показал мемори ликов на 4кб. Надо будет глянуть.. это конечно не 4мб, но если там не дебри, то почему бы не пофиксить...
==16965== Thread 9:
==16965== Invalid read of size 4
==16965== at 0x405F7A5: LockGet (ow_locks.c:142)
==16965== by 0x4066195: FS_r_given_bus (ow_read.c:229)
==16965== by 0x40663B2: FS_read_distribute (ow_read.c:191)
==16965== by 0x40668AD: FS_read_postparse (ow_read.c:106)
==16965== by 0x4066AEA: FS_read (ow_read.c:58)
==16965== by 0x409E26D: fuse_fs_read (in /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40A2A12: (within /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40A5F48: (within /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40A6EAF: (within /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40A86D5: fuse_session_process (in /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40A4AD4: (within /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40C8382: start_thread (in /lib/libpthread-2.7.so)
==16965== Address 0x43b8dc8 is 0 bytes inside a block of size 16 free'd
==16965== at 0x402465C: free (vg_replace_malloc.c:323)
==16965== by 0x41B281A: tdelete (in /lib/libc-2.7.so)
==16965== by 0x405F62B: LockRelease (ow_locks.c:164)
==16965== by 0x40662AD: FS_r_given_bus (ow_read.c:236)
==16965== by 0x40663B2: FS_read_distribute (ow_read.c:191)
==16965== by 0x40668AD: FS_read_postparse (ow_read.c:106)
==16965== by 0x4066AEA: FS_read (ow_read.c:58)
==16965== by 0x409E26D: fuse_fs_read (in /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40A2A12: (within /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40A5F48: (within /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40A6EAF: (within /usr/lib/libfuse.so.2.7.3)
==16965== by 0x40A86D5: fuse_session_process (in /usr/lib/libfuse.so.2.7.3)
Пропатченная версия работает уже 2 часа без проблем. Если до вечера доработает без ошибок напишу в mailing list owfs.
Патч.
P.S. Valgrind показал мемори ликов на 4кб. Надо будет глянуть.. это конечно не 4мб, но если там не дебри, то почему бы не пофиксить...
суббота, 17 мая 2008 г.
!@#@#$@#$
3 часа строить АЧХ на тупой RC фильтр в Altium Desginer пытаясь понять, почему расчетное f=1/RC не работает для R=4.7M и C=2.2uF.. Чтобы потом выяснить, что в нем приставка мега пишется как Meg, а не M. А M на самом деле означает мили... Дошел до этой мысли подставив 4_700_000 вместо 4.7M на третьем часу ударов головой о стену..
Подписаться на:
Сообщения (Atom)
Сообщения
