кризис власти

ну че же мне за начальник такой попался?! вот ведь ничего не понимает что мы там делаем, а лезет как нам “сырец” по СВС раскладывать, структуры создавать и вообще…* а тут я еще, с подельником своим, не приду никак к согласию об устройстве наших гениальных систем. я рушу все старое, и новое прогрессивное строю – JSP, сервлеты модные, а он старье на Свинге переписывает… так и мечемся, а начальник наши метания по своему понимает и советы несуразные дает…

Однажды лебедь, рак, да щука
Везти с поклажей воз взялись,
И вместе трое все в него впряглись;
Из кожи лезут вон, а возу все нет ходу!
Поклажа бы для них казалась и легка:
Да лебедь рвется в облака,
Рак пятится назад, а щука тянет в воду.
Кто виноват из них, кто прав,- судить не нам;
Да только воз и ныне там.

чур, я лебедь! а так хотелось самостоятельности и вселенского счастья… как-бы мне их свергнуть? или улететь от них нахрен? – за#$%^&!

*нельзя не признать, что начальник-то очень неглуп, неглуп, хрен-ли? – мы у других не работаем! 😉 он шарит в бондах, финансовых рынках и прочих деривативах, очень стрит-вайз, но слов “стратегия”, “планирование” не знает вообще, про слова Джава и не говорю.

не потреблять!

как-же я не переношу потербительское отноешение ко всем нашим IT штукам! конечно, я понимаю, что все эти компьютеры нужны для дела и некогда восхищаться “красотой архитектур построения IT систем”, но хоть вид сделайте, притворитесь, что миллионы транзисторов в одном чипе это круто – жалко вам что-ли? 😉

нужна-ли “слжность” в Java?

вот оно о чем я всегда говорил всем этим “очкарикам” которые брызгая слюной отстаивали достоинства очередной системы абстракции – новой framework (как framework на русском?) – не нужно это все если уж жизненно не необходимо для приложения…

Вот статья, коорая это все объясняет:

Just enough, and no more

A posting at dzone this week, “Thinking In Java: Do you really need a Persistence Layer?” made me think. One of the recurring themes in Java community discussion during the past couple of years has been the complexity of J2EE, and especially EJB. One could argue that the rise to prominence of frameworks like Spring and Hibernate is a direct reflection on the complexity of using the de facto “standard” approach of using only the J2EE stack. Yes, I am aware that J2EE is officially standardized through the JCP, but I don’t think this type of broad, sweeping standard necessarily carries the same weight or the same intrinsic merit as some of its component parts like servlets, JDBC or JavaServer Pages. We may automatically adopt and employ certain technology standards, but others have to prove their value.

The “standard” J2EE covers a lot of territory, and few of us today are prepared to swallow it hook, line and sinker merely because it has been approved by the JCP organization. Here at DeveloperZone we may be shortsighted, but I can tell you that Matt, Mike and I never even gave serious consideration to a full-blown EJB-based architecture for the technology that powers dzone.com or the upcoming revisions to Javalobby and EclipseZone. It was pretty much a no-brainer to use Spring for the basic web application, and our toughest choices pertained to whether or not we would use Spring’s Web MVC layer and to which persistence strategy was most likely to work well. Looking at those same choices today, I think we probably would have given more consideration to Java EE 5 and its simplified architecture for EJB3 and web services. The updated “standard” approach seems to match our needs and expectations better than the old one did.

But are we, collectively speaking, viewing such issues from a perspective that is fundamentally too complicated. Is it really a choice between one ORM layer and another, or are there times when you can do quite well without having a full-blown persistence layer at all? Humans are creatures of habit, so we tend to use familiar approaches when evaluating how to solve problems, and the use of a persistence layer is arguably one of the most familiar facets of typical application architecture. The blogger who wrote the post I mentioned above, Iceman, suggests that we can sometimes reach our goals without an official persistence layer, especially a full-fledged database-oriented persistence layer. Iceman favors a KISS approach that provides sufficiency to a presumptively heavyweight approach.

He does not, however, suggest that you never need to adopt the more complicated approach. There are many times when, whether for prudence or scalability, you have no other choice. What I think Iceman is suggesting is that we ask ourselves the question, “How much is just enough?” and it is a mightily worthwhile question to ask. How do we do just enough to get the job done, and not a bit more? I’d be a big liar if I tried to pretend I had never made choices that unnecessarily complicated projects, and sometime those choices have led to projects that significantly overran schedules and budgets, or even which completely failed! Figuring out how to do “just enough, and no more” may be the strategy that allows your project to fall into that minority of those which are completed successfully, on time and on budget. I know there have been times when I’d have been smarter to focus on “just enough” than on problems like future scalability. An application that never gets delivered has no future needs no future scalability.

Read what Iceman has to say. I think you’ll enjoy it. You may not agree with his specific choices, but I bet you’ll recognize the merit of his basic approach to do just enough to get the job done, and no more.

Why Ruby Doesn’t Interest Dave Glasser
The whole world seems to be talking about why Java isn’t sexy and fun anymore, as if the “newcomer” Ruby is just intrinsically superior. Dave Glasser doesn’t agree, and you may enjoy his thoughtful posting “Why Ruby Doesn’t Interest Me” at Javalobby. Dave is a valuable contributor to the Javalobby community, so I’m happy to know he’s not planning to give up on Java in favor of Ruby any time soon!

Until next time,
Rick Ross
rick@javalobby.org
AIM or Yahoo Messenger: RickRossJL

как принимать решения и вообще

Высказывание обобщающее принцип принятия сложных решений и преводящее этот принцип из области программирования в плоскость принятния жизненных решений:

“…Судите сами: если однажды принятое решение можно легко изменить, то его правильность становится менее важной. А это делает жизнь много проще. [При эволюционном стиле проектирования дизайнеры должны стараться принимать легко обратимые решения] И вместо того, чтобы мучительно отыскивать единственно правильное решение, нужно или постараться отложить его принятие на потом (когда у вас будет больше необходимой информации), или же принять такое решение, которое в будущем можно изменить без особых усилий…”

“Проектирования больше нет?” вообще, статья хоть и для “очкариков” от программирования, но написана интересно.

Oracle – дрянь!

какая же Oracle дрянь! самые простые вещи делаются, я прощу прощения, через жопу! и опять мне приходиться все с ним ковыряться из за того, что маркетинг Oracle качественно пудрит мОзги всем IT менеджерам, что Oracle самая надежная/производительная/отказоустойчивая/функциональная далее по списку ДБ. кому нахер это все сдалось, если никто этим не пользуется!

Скажу по секрету – тссссс! – в одной большой компании (World Top 13 ICT) во многих корпоративных ДБ Oracle не используют индексы! вообще! потому что нахер непонятно кто за эти ДБ и индексы будет крайний, ибо это уже копроративная политика… еще скажу, что “незрелая для корпаративного использования mySQL” (потому что мозги не умеют еб&^%*) у меня на хилой вообщем-то машине ворочала таблицы с 142 миллионами записей! и ничего, не падала, скрежатала дисками, но не падала и реально работала! У Oracle-a на такую мащину вообще бы не встал. 😉

Сделали ли бы они свой PL SQL не таким капризным, простые вещи простыми, а сложные просто возможными, но без этого мерзского налета, что это может только Oracle! а пока я их ненавижу!