умные глянец издают

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

пару цитат из фильма отражающие настроение:
умные глянец не читают, умные глянец издают!
что не продается, то не искусство [в контексте моды]
все люди делятся на тех кто покупает, продает и тех кто продается

песня “апрель” М.Покровского, которая ровно ложится в настроение фильма, хотя там ее не было, лишь моя больная ассоциация.

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

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

драма на работе

когда я в Ипсвиче мечтал о Лондоне, то я хотел работать заниматься “настящим делом”, чтобы не было 25 бестолковых управленцев над тобой со своей корпоративной лабудой глобальной компании. 

работа нашлась. лишних дураков нет. только самые необходимые. вот эти “слишком верхние” мыслят своими не то-чтобы абстрактными, но вполне банальными и приземленными понятими “повышения эффективности, увеличение функциональности, уменьшения стоимости” и чтобы все было в красивых экранных формах.

вникать в подробности технологий их статус не предпологает.  технологические вопросы в их понимании решаются “какой-нибудь другой технологией” и просто идут отдельной строкой этих их бюджетных раскладок.

меня, как непосредственного исполнителя, вопрос: “что это с этим работать не будет и вообще так не делают” очень даже волнует. но как мне обяснить, что “крылья от Боинга которые им впарили на последней IT выставке, ну никак ни приделать к их одноместному самолету”?

образовывать их всех сил не хватает… выглядишь как повстанец и саботажник критикуя их “прогрессивные идеи”. налицо конфликт интересов, а значит драма на охоте работе.

все усугубляется их безумно самоуверенным отношением к миру, как оскзалось, очень свойственным всем финансистам. решения ими предлагаемые настолько наивны, но чтобы они это поняли им надо пару лет учится технологиям… и как с этим жить? может гугл свой придумать и стать знаменитым?

морские шмотки

морские шмотки
были на выстваке морских шмоток в Гринвиче. это часть ежегодного проекта Fashion Week в Лондоне. собраны все, что так или иначе относилось к одежде у моряков и околоморских людей. время исчисления собственно с того времени когда люди плавать начали. все это прозвано морской модой.

что могу сказать? ну прикольно, но о чем я больше думал когда смотрел на монографии посвященные системному исследованию морских ленточек, журналы про морские воротнички или фотографии модных коллекций 60х a la mer, а что это так важно и кому сдалось кроме исследователей этих ленточек? по-резултату, получилась эксплуатация морской темы в личных интересах…

нужна-ли “слжность” в 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