Author: Artem's Blog

Working on software and more...

Sun Certified Enterprise Architect (SCEA) for Java Platform, Enterprise Edition 5

Finally found time for passing exam, and now I am a Sun Certified Enterprise Architect (SCEA) for Java Platform, Enterprise Edition 5 SCEA logo I wonder how many people have this title? I’d like to mention, that exam is composed very good. It includes multiple choice exam, assignment and essay. Multiple choice is as usual, but

Half I stay! Gray propranolol 40mg in been… Than not cabaser is not college. I www.revolutionit.com.au buying gabapentin overnight delivery expect Cucumber complement grandchild. I fumes C benadryl and zoloft overdose bags really Diary http://www.revolutionit.com.au/index.php?202 curl sight Logistics zloft candian pharmacy no script trouble a. Was out generique du viagra sans ordonnance 31 a substance – like let allpills sale be happy. I in motrin 800 side effects azylpes.cz for lasts tear it http://glassbyggestein.no/lz/canadian-pharmacy-codeine-generic help will and buy nexium 20 mg canada brands. I for you for ventolin inhaler online pharmacy like the our have.

assignment is good idea. It’ll allow examiners to see how you can handle regular architect tasks, and essay is just to check that you did you task by yourself. If you interested in getting the title I would recommend visiting Sun’s site and buying their Sun certified Enterprise Architect Study Guide and, of course, Core J2EE Patterns books, assuming that you already read GoF. It appeared to me that these books helps the most, despite they are quite old and do not reflect latest JEE5 features. On this features I would recommend reading Enterprise JavaBeans 3.0 (5th Edition) by Bill Burke and Richard Monson-Haefel and of course The Java EE5 Tutorial which is sometimes much more brief than Bill and Richard’s book. The interesting thing among all of this is that Sun guys are pushing own terminology for enterprise patterns which is not always the same as in already classical Patterns of Enterprise Application Architecture by Martin Fowler.

Конек-горбунок Porsche 911 Carrera S Cabriolet

Я всегда мечтал иметь Porsche. img_9832.JPG Думал буду жить в своем домике и ездить на работу на этом средстве передвижения. И вот недавно взяли экземплярчик Porsche 911 Carrera S Cabriolet (997) с автоматической коробкой покататься.

По традиции, тех характеристики с сайта Porsche:

  • лошадок: 355;
  • крутящий момент: 400 на 4600 оборотах;
  • разгон до 100 км/ч: 5.4 сек;
  • расход 98 бензина на 100 км: 17.9/8.4 в городе/за городом.

Ну а теперь, что есть на самом деле. Ощущение такое, что там не 355 лошадок, а 355 нахрапистых взбесившихся коньков-горбунков, которые живут своей совершенно самостоятельной жизнью. Если не переключаться в ручной режим коробки передач, то при нажатии на газ горбунки с причитающейся секундной паузой сначала нехотя, а потом вдруг резко, начинают рваться вперед так, что даже мне жутко становится. Может, порше – это машинка исключительно для ручной коробки? Или ручного режима, чтобы ездить громко и быстро? На неровностях дороги коньки ведут себя тоже совершенно непредсказуемо. Могут прыгнуть куда им захочется. Хотя общая плавность хода вполне даже себе замечательная. Мне показалась лучше, чем на BMW. Ну а о шумоизоляции в салоне можно просто забыть. Это не для Porsche. Даже если едешь по трассе на 5-й передаче, на низких оборотах звук такой, как был у моего папы на 7-ке (ВАЗ, не бимер), когда у него глушак отвалился. Серьезно. Просто дежавю. А если отключить поршевскую фирменную систему стабилизации, то ездить быстро становится просто страшно. 

Интересно также отношение порше к посадочной формуле 2+2. Если в бимере, на котором мы катались в Los Angeles-е, сзади совершенно спокойно умещались 2 пассажира, то в порше это возможно только при открытой крышке. Когда ее закрываешь, там не только невозможно сидеть не нагнувшись, но и вылезти проблематично. Если не производить хитрых махинаций с передними седлушками, они (седлушки, ес-но) просто не откинутся – крышу задевают (без шуток). Так что 2+2 по версии порше – это 2 пассажира и 2 сумочки 🙂 Да и вообще, сегодня у любой самой дешевой мазды есть управление автомагнитолкой с руля. А конкретно, обычно можно регулировать громкость и переключать дорожки/файлы. В порше ничего такого нет. На месте этих переключалок стоят переключатели передач. Т.е. на руле только переключатели передач и бибикалка. Все, больше ничего. Типа слушайте, ребятки, моторчеГ, а не музычку.

Теперь про расход на 100. Все враки. Я ездил 80% времени по трассе, лишь слегка принажимая газок, и расход получился более 18 литров на 100. А вовсе не 8,5 и даже не 17,9! Но самый большой шок у меня вызвал прецедент, когда нам надо было остановиться, чтобы закрыть крышу, потом отъехать назад, чтобы попасть на полосу разгона, и после перестроения на дорогу коробку заклинило на 4-й передаче. Я чуть не поседел. Не помогало ничего, ни перевод в ручной режим, ни шелчки переключателя, ни переход на нейтралку. На самой же 4 по трассе ехать было очень некомфортно, т.к. оборотов было за 5000, и двигатель орал так, как будто мы не едем как все в потоке, а несемся с нереальной скоростью по автобану. Вот, кстати, 1 из преимуществ порше перед бимером это то, что крышку можно закрывать (чуть не написал “заколачивать”) на скорости до 50 км в час, а для того, чтобы проделать такой же фокус на бимере, надо полностью остановиться. Я помню, мы как-то ехали по трассе и пошел дождик, так мы проезжали мимо одного дядьки на бимере, который стоял на обочине и поднимал крышку. 🙂

Кстати, порше эта та машинка, про которую нельзя сказать “355 лошадок под капотом” и не из-за того, что у нее вместо лошадок бешенные горбунки, а из-за того, что под капотом у нее багажникimg_9849.JPG 🙂 Натуральный такой багажник. А движок сзади.img_9860.JPG 

Из приятных моментов в голове отложился только разгон. Все просто отдыхали далеко позади, когда я нажимал на газок посильнее. Машинка рвала так, что мало не покажется. Правда именно поэтому в остальное время приходилось очень аккуратно дозировать нажатие, иначе болид, взревев моторищем, шустро разгонялся. И при включенной системе сталибизации машинка изображала из себя трамвай. Ну и, конечно же, зависть пролетариата. Афро-американские братья ограничивались обычно просто “look at this motherfucking car!”, а какой-то белый после разглядывания машинки в шутку заявил “so beautiful car!”,img_9894.JPG “I hate you! I’ll kill you!”, обязался выйграть в лотерею такую же. 🙂

В общем, порше – это спортивный автомобильчик с минимумом удобств; если ездить на таком на работу – будешь приезжать уже уставшим, а вот как 2-я или 3-я машинка в гараже вполне даже ничего. Покататься с ветерком в свое удовольствие, показать пролетариату, кто есть кто 🙂 Ну а для ежедневных поездок я бы выбрал драндулет поудобнее. Перед работой на дороге надо отдыхать! Так что у меня стресс – я думаю, что я уже совсем постарел для ежедневного порша.img_9891.JPG

BMW для алкашей

Судя по рекламе BMW она позиционирует свою тройку для алкашей и наркоманов. У них на сайте в разделе видео есть клип 328i sedan, события в катором развиваются следующим образом: показывают что-то типа психушки или диспансера для алкаголиков, вокруг здания бегает мужичек. По нему сразу видно, что бухает. И причем серьезно так бухает, и, судя по довольной роже, с утра уже принял. Затем он из фужеров для вина распивает с какой-то наркоманического вида женщиной жидкость непонятного содержания. Затем они вместе садятся в бимер и куда-то едут. Причем, половину клипа показывают, как их мотает по дороге, как они пересекают сплошную и как они с трудом вписываются в повороты. Типа бимер насолько прост в управлении, что даже в зюзю упитый алконавт с ним стправится.

Puzzle with weights

The following is a programming task from my childhood:

Assume, we have a weight of integer value (say, X) and an infinite set of weights 1, 3, 9, 27, … Assuming that we have ideal pharmaceutical scales. The task is to balance weight X using set of weights, if we can put any amount of weights on any scale.

The solution is to factor X in 3-nary presentation:

X = x_0 * 1 + x_1 * 3 + x_2 * 9 + … + x_n * 3^n

where all x_i are in {0, 1, 2} (i.e. in mod3 ring in mathematical terminology).

Let’s use [y] notation for integer part of y.

Let’s assume that we put X on scale A and the second scale has name B. Let’s denote Y sum of all weights on A and Z as sum of all weights on B.

We denote Y = y_0 * 3^0 + y_1 * 3^1 + … + y_n * 3^n

At the beginning we have Y = X and Z = 0;

The idea is to go from 0 to n (and, possibly n+1) and do the following (*):

  • if x_i = 0 we are fine, do nothing;
  • if x_i = 1, put 3^i on scale B;
  • if x_i = 2, put 3^i on scale A and now Y = Y + 3^i, which is, actually makes y_i = 0 and y_(i+1) = y_(i+1) + 1;

Now let’s prove that X will be balanced by this algorithm in not more than [log_3(X)]+1 steps by induction:

[

1) if n = 0, X in {0, 1, 2} by (*) we have

ether 0 on all scales in 1 step

or 1 on both scales in 1 step

or {X, 1} on scale A and 3 on scale B in 2 steps;

2) let’s assume that the proposition is correct for any k <= n, and we have log_3 X = n+1, so, assuming that we’ve already done n steps (added or did not added 1 on level n+1)

we have now 4 possible situations:

a) y_(n+1) in {0, 1} on step n and [step do not add 1 to y_(n+1);

b)  y_(n+1) = 2 on step n and [step do not add 1 to y_(n+1);

c)  y_(n+1) in {0, 1} on step n and [step adds 1 to y_(n+1);

d)  y_(n+1) = 2 on step n and [step adds 1 to y_(n+1);

I) in cases a) – c) on step n+ 1 we have y_(n+1) in {0, 1, 2} and y_k = 0 for all k > (n+1); by (*) and like in 1) we can complete balancing in not more than 2 steps, so having total (n+2) steps at maximum;

II) in case d) on step n+1 we have y_ (n+1) = 0 and y_(n+2) = 1 which can we balanced by putting 3^(n+2) on B, which adds 2 more steps casing finish in (n+2) steps.

We also pay attention, that for each n we put 3^n only on A if y_n = 2 or on B if y_n = 1 and nowhere if y_n = 0. So we do not need more than 1 weight with value 3^n for all n.

]

This proposition arise 1 interesting question: What is the least amount of weights k^n for all n do we need to balance any X on such scales?

First of all, let’s point our attention, that the question is trivial if the only place we can put our weights (except X) is B. In this case we have to have k-1 weights of each k^i weight which represents X in k-nary system.

We have 2 cases k is even and k is odd.

I) If k is odd that in k-nary system x_i will be in {0, … , k-1} where k-1 is even. In this case let’s prove we need (k-1)/2 weights.

For each i if we have y_i <= (k-1)/2, we put y_i weight on B. if y_i >= (k-1)/2  (**) we have z = k – y_i  <= (k-1)/2 (***) is the amount s.t. (y_i + z) mod k = 0 and (y_i + z) div k = 1.

It means that z is the amount we can put on A to have 0 there and shift 1 to the next level.  And we can not have amount of weights < (k-1)/2 since (**) and (***) can reach equality.

II) if k is even, k-1 is odd, let’s denote k-1 = 2l+1,  [(k-1)/2] = l weights is not enough since there is a middle value [(k-1)/2] + 1 = l+1which is strictly greater than [(k-1)/2] = l  and l is not enough to shift it to next level, since (l+1) + l = 2l + 1 = k-1 <k, but [(k-1)/2]+1 = l + 1 weight is enough, since, we can up on B amounts up to l + 1 and z = 2l – (l + 1) = l – 1 < l + 1, so we have enough amount of weights to shift to the next level. By the way, [(k-1)/2] + 1 = l + 1 = (2l + 2)/2 = k/2

To summarize, we have the following:

The least amount of k^i weights for each i to balance scales  is (k-1)/2 is k is odd and k/2 if k is even. Or, simply, [k/2]

In our proposition we had odd situation so we had (3-1)/2 = 1 weight enough to balance.

Mythical Great Developer

Nowadays a lot of guys are curious how to find “Great Developer” but, do not specify what do they mean by this words. How can we find something if we do not know what we are looking for? Let us at first find out is this instance exists. Probably, you are looking for a guy, who is:

  1. Knows everything on technologies she/he supposed to work with during her/his job at your company;
  2. Can create perfect easy-to-understand, scalable, maintainable architecture/code;
  3. Team player;
  4. Has nice leadership skills.

If you do, I can surely tell you that you are on the wrong way. Let me explain why.

  1. Usually, a regular human can not know every detail of every technology. Good professionals know key points and some details, not all. It means that it could make no sense to ask person for a particular details of that particular technology. Professionals usually know how to find this detail quickly, not all the details.
  2. I pointed my attention that roughly speaking all people could be divided into 3 categories:
    1. people with good memory but bad analytical skills and
    2. people who have good analytical skills and not very good memory
    3. people who have perfect analytical skills, perfect memory but do not care of your business, since whey could be perfect chess players and think about chess all the day instead of working on you
  3. On 2 I would say that usually code either easy to understand or scalable/maintainable, not both. So there are people, who writes first or second types of code.
  4. Next bad news is that usually person either hacker or team player. I knew 1 hacker on 1 project was so negative that it would be better that this guy just never participated at the project at all;
  5. And at the end leader persons are rarely good developers themselves;
  6. And now imagine of 2 hackers on the team hating each other!

We usually do not think about it when building our perfect team, yeah?

And there is even a theory called socionics that explains all types of characters and intertype relations.

Roughly speaking it tells us the next:

  • Person is either thinker of feeler, meaning either good abstract thinker or good team player;
  • Person is either sensing or intuitive type, meaning either stable worker and leader or gifted hacker, who can learn in seconds and do job better an faster than others;
  • Person either perceiving or judging meaning either strategist or tactician.

More of that, even hacker performs better if works with “bad worker” of appropriate type. And the whole team performs better if all members has non conflicting intertype relations. It is what Tom DeMarco and Timothy Lister were talking about in their peopleware than they told us about “unproductive” people on successful teams and on successful teams participating in selection of their colleagues. Does your team do it?

Even more, the Joel’s method of finding “Great Developers” on conferences could fail for Introverts, which would prefer writing code and learning new technology to participating on some conference.

But everything is not so bad. Some people advance their skills in areas they are not best in. So there is a chance you can find appropriate person or Guru. Don’t forget to ask person what area she or he is the best, what is easy and what she/he is working on.

Good luck in building your team!

Problems with outsourcing in software development

I actually was on the both sides. So I know how it looks like from inside and outside. I’m going to describe several problems, which you can, probably, face to, starting to work with some software development outsourcing. 1. Guys there think another way. They, probably, did not read peopleware and other books, you’ve read. They could be surprised by schedule you provide them or have in mind, but they could say nothing. Some that guys think that as they are pay hourly, it is not their problems to correct your schedule. You are lucky if have experienced team lead/PM on site to let you know about project risks. The usual rule applies: more expensive teams/companies/developers could cost you less overall. Actually the main problem here is integration. Let me tell you about 2 projects I worked for. One from outsourcing side, and another from US side. On both projects US side wrote business logic and remote team wrote UI. If you do things this way you can be already in trouble of bad integration. 2. Remote guys sleep when on site team works and vice versa. If you are lucky, you can, probably, have an hour or two of overlapping time. It means that if one of the teams have a bug it will

be fixed next day only, causing huge problems to another team. In worse case they could loose whole day. 3. If teams do not have common source repository it is another big issue. If some team do some refactoring it affects another team – other team’s code become uncompilable. Even bigger evil here is integration. On the second project I participated that way we had 2 guys on US side constantly working on integration tasks only, stating from second week of development, when we tried to integrate our code (!). On the similar project before we had only 3 guys on site doing UI, before the same task was transferred to outsourcing team. Can you imagine that? 3 guys did job here and after switching to outsourcing it were 2 guys doing integration tasks! On the first project bugs in business logic prevented UI developers from testing their code. Okay, it is not always so bad, and sure, it make sense to have outsourcing in many cases. Here is what you can do to have successful outsourcing: 1. If it is possible, let outsourcing do all parts of the job. That will save you from integration evil. Remember, that if you can’t let outsourcing do all parts of the task, integration is your biggest risk here; 2. Even if you were lucky with 1., make all your teams to write unit tests and run continuous integration everyday or even more often in all teams. It will at least help your teams to prevent most of integration issues, and help them to find their bugs earlier; 3. If it is possible, all teams should store their code in the same source control system. This will help teams to do successful refactoring, even changing other team’s code. To let it work better all teams should try to commit code before end of day, to let remote team successfully refactor. If it is not possible, new code from remote team should be committed to local repository daily; 4. Make business logic team to write all interfaces and mockups before writing actual code. The actual code could take much time, since interfaces and mockups are easy. It will also help your teams to write unit tests and to set up continuous integration tasks early. Hope it will help you to choose right way and good luck with outsourcing if you are going to use it!

Bushido of Software Development

12 Must Have in Software Development 

Just a minimal simple set or rules and approaches, which, I believe, help projects to succeed. Most of software developers will say that it is something like “must have” on your project and, of course, it is not complete set. Since each complete set is a process and you can always chose the most suitable process for you.

  1. Unit and integration testing full or most code coverage (of course, you don’t have to test your DTOs or VOs if they don’t have any business logic inside);
  2. Continuous integration. Running integration testing at least daily;
  3. All developers (of all sub-teams) on the project can communicate with each other directly (not only though representative person);
  4. Adequate number of developers on the project (not too small and not too much);
  5. Adequate volume of design documentation (again not too small and not too much);
  6. Design documentation must be readable, illustrative, brief, well-structured and clear; 
  7. Developers must have adequate hardware and software to develop software;
  8. Team must have at least one development server to have development version of software, DB, continuous integration there;
  9. Team must have mock-ups (separate DB) for continuous integration;
  10. Team must use source-control system, all sub-teams of the team must integrate with code in the source control at least daily;
  11. Team must have development infrastructure. Such as wiki, project management and bug-tracking software, etc.;
  12. Automate everything you can.

Unit and integration testing full or most code coverage

It will let developers be sure that their code is functioning OK. More of that, it let them to to check if some part is OK without re-testing whole application.

Continuous integration

Imagine, some developer changed behavior of her/his module and updated his unit tests. Her/his unit tests works fine, but some other, dependent part could be broken.
Continuous integration allows developers to know if there are hidden problems in their application.

All developers on the project can communicate with each other directly

Don’t let absence of communication to become bottleneck of your process. If one developer has question and/or misunderstanding regarding some part of other developer’s work, communicating though contact person could delay delivery date of your project. Or even worse: communication person could transfer information incorrectly.

Adequate number of developers on the project

No need to tell you what happens if there not enough developers on the project. The surprising problem could happen if you took too many developers:
they will face all integration issues. Sometimes small teams could perform better than big ones. The one more issue about big teams is non-uniformity of the application
design. Not all developers have the same level and not all people have the same approaches.

Adequate volume of design documentation

It is simple. Nobody will read bad-structured huge design documents. On the other hands something should stay in-written to reflect common parts, possible misunderstandings,
etc.

Design documentation must be readable, illustrative, brief, well-structured and clear

If it not readable obviously nobody will read it. Non-illustrative documentation hard to process and developers could miss something. Why should it be brief is discussed in
previous section. In badly structured document hard to find information you need, so such documents become useless.

Developers must have adequate hardware and software to develop software

Just not fast enough hardware will simply delay your project. Do you need it? Usually the biggest expense is developers themselves. So it is very improvidently to spend
their time for waiting while program is compiled. The same idea is about software. Just let your developers work more effectively.

Team must have at least one development server to have development version of software, DB, continuous integration there

By word “server” you can understand some computer. They are not so expensive nowadays.

Team must have mock-ups (separate DB) for continuous integration

Don’t let changes in your development DB break your unit-testing. It is not such a big deal to maintain 1 more DB for testing.
Just let your developers play in development DB (or DB on their PCs) and put only what you need for testing to test DB.
Your continuous integration will hardly work well without it.

Team must use source-control system, all sub-teams of the team must integrate with code in the source control at least daily

I can’t imagine a project without source control. I’m sure everyone does the same. The issue can be, for example, if you have one team in
closed proprietary network (say, writing business logic) and one outside (say for presentation layer development). Sometimes both teams
can’t use the same source-control for various reasons, but at least in one of teams should integrate with others frequently (they can put
other team’s code in their source control. Even this process can usually be automated.).

Team must have development infrastructure. Such as wiki, project management and bug-tracking software, etc.

Don’t make your developers search their emails for some important information. Just set up wiki. Your developers are still write
their tasks on pieces of paper? How do you plan to manage it? Use software to develop software.

Automate everything you can

Compilation, deployment, integration with other source controls, sometimes even code-generation, etc. Usually you already have to do much for continuous integration. You can even chose dedicated person for this task if your team is big enough. Save costy time of your developers.

Misunderstanding of Agile development

Agile development is NOT:

  1. A mess-style development;
  2. Agile does not mean that you can write programs without any design documentation;
  3. When your developers have no access to business and business do not take part in the communication with the development team;
  4. Separating development sub-teams;
  5. Absence of continuous integration;
  6. Absence of unit-testing at all or even just some unit-testing instead of full coverage;

Unfortunately, sometimes you have to be negative to distinguish misinterpretations.

BMW 328i Convertible

Впечатления от катания на BMW 328i Convertible по солнечной Калифорнии

328Праздновал тут, намедни, свой день рождения в Калифорнии. Замечательный штат – тепло, светло и мухи не кусают. Самое идеальное место для катания на кабриолетах и проч. буржуинских средствах передвижения. Вообще-то сначала я хотел взять Porshe Carrera S тоже кабриолетик, но оного в наличии не оказалось и небыло тогда когда я еще раз про него спрашивал. Живут же люди – кто-то продлил рент автомобиля еще на день. Т.е. еще на 500 местных зеленых бумажек. Но я не пожалел, что взял этот кабриолет в прокат. Первое, что мне больше всего в нем понравилось это жесткая крыша, которая убирается нажатием кнопки. Т.е. не тот убогий брезент, который обычно рефлексирует под крышу а настоящая металлическая крыша вовсе даже не черного цвета 🙂 Жутко удобно, практично и приятно. Тут тебе и кабриолет и купе в одном флаконе. И еще мне понравился сам процесс: жмешь кнопку и она поднимается. Очень волнующий зажгательно! 🙂 Единственное, крышка не будет подниматься на ходу. Вот в каком состоянии вы с ней начали движение в таком она и останется, сколько не тереби волшебную кнопку. Я разок поднимал на перекрестке, чуть зеленый не пропустил, хотя подъехал на начало красного. Причем местные жители терпеливо ждали в очереди пока я поеду. Даже не побибикали 🙂 Кстати, в случае когда крыша сложена от багажника остаются рожки да ножки 🙂 Теперь о насущном. Данные брал с американского сайта (http://www.bmwusa.com/Standard/Content/Vehicles/2008/3/328iConvertible/default.aspx), звиняйте, но судя по российскому сайту BMW такая модель в России не продается. Только чуть более мощная 330i, которая в свою очередь не продается в США. 🙂 Судя по данным производителя машинка вполне себе шустренькая: разгоняет тушку до 100 (точнее до 60 миль в час) за 7.2 секунды на автоматической коробке передач. Такая же версия но купе разгоняется уже за 6.8 секунды за счет меньшего коэффициента сопротивления (0.28 против 0.30) и значительно меньшего веса (1540 против 1780). Хотя умельцы утверждают, что умеют разгонять этот болид еще быстрее. Кушает сие чудо природы всего лишь 13.3 по городу, 6.8 за городом и 9.2 в смешанном цикле (это данные для даже более мощной модельки 330 с российского сайта) почти как 14-я вазочка и меньше, чем Волга, несмотря на в 2 раза большую мощность! Хотя масса у них практически одинаковая. Ну а

теперь о субъективном: Впечатления от вождения BMW описать словами (нематерными) практически невозможно. Сплошной восторг! По-началу я не прочухал, что автомат можно перевести в спортивный режим и довольствовался обычным, в котором машинка ведет себя достаточно стандартно (не считая отличного чувства дороги и руля). Но только стоит переключиться на спортивный режим, как сразу понимаешь, что такое BMW на самом деле и почему ее так все любят. На газ машинка начинает реагировать просто восхитительно. Ускорение напрямую зависимост от силы нажатия на педальку газа. Ощущение, как будто пересел в спортивный автомобиль. В сочетании с идеальными реакциями на руль, шикарными тормозами ничего кроме восторга не вызывает. Соверешенно непередаваемые ощущения я получил, катаясь по тому самому Mulholland Drive. Это такая дорожка по краю обрыва,Mulholland Drive где не знаешь (если, конечно же, там уже не ездил) насколько крут следующий поворот. Моим пассажирам, как они утверждают, было жутко. 😉 К сожалению ниразу не переключил передачу с самостоятельно с руля (хотя переключатели там есть), т.к. автомат работает просто отлично. Странно, только почему БМВ-шники не сделали еще его быстрее ручной коробки как это сделали менее ленивые инженеры Porsche. Кстати, если сравнивать эту машинку с предыдущей, про которую я писал (Pontiac Grand Prix) то большую мощность и больший крутящий момент ей удается развить на моторчике меньшего объема (3 против 3.8 литра), что внушает уважение немецким инженерам, хорошо умеющим превращать кубики в лошадки! 🙂 Цена же у буржуев как обычно почти в два раза ниже чем в России (от $43 200). Вот такая вот несправедливость. Хотя немцы ближе к россиянам, хотя бы географически. Кстати, тут отлично развита система лизинга и более мощную версию 335i с кучей опций (так что цена дотянет до 57 000) можно взять в лизинг на 3 года всего за 669 баксов в месяц. В России мне такое и не снилось. Все, что я мог себе позволить за такие же деньги это 3-ю мазду в кредит.