тут недавно писали о проблемах отечественной электронной промышленности… А тут с молотка продается один из гигантов вкупе с технологиями, рынками и пр…
Надо понимать, что любой анализ делается под заказ. Здесь нам тупо впаривают второй сценарий как преимущетсво глобализации и транснационального контроля. Собственно он и является наиболее вероятным. Только не все написано.
Сценарий 2 (продолжение)
Резкое расслоение уровня доходов приведет к четкому формированию двух классов: «владельцев», получающих доход по праву владения и «обслуги», вынужденной продавать себя и свой труд. Для «обслуги» населения жизнь внутри мегагородов становится не по карману, и они постеменно смещаются на периферию. Мегагорода обрастают большим числом городов-спутников, куда переносится все производство и обслуживающие сервисы, и где сконцентрировано основное население региона. Внутри мегаполисов концентрируются исключительно транснациональные корпорации, финансовые структуры и районы с особняками. Мегагорода ограждаются от периферии барьерами, въезд за которые возможен только по визе или спецпропуску. Наоборот, между мегагородами отсутствуют всякие ограничения на передвижение и торговлю. Постепенно внутри класса обслуги также происходит расслоение на тех, кто работает на мегаполис (относительно высокий доход), и тех, чей источник доходов находится внутри периферии. В итоге периферия разделяется на «ближнюю» и «дальнюю». Для бОльшего экономического контроля над периферией регион вводит собственную валюту.
Xamarin.com в данном случае впереди. Он позволяет и логику и GUI писать на C# для iOS и Android. Но, к сожалению, API GUI не совпадают. А GUI — это 80% всей апликации. Тем не менее, иметь подобный конвертер — полезная вещь.
Помню, программы на Turbo Pascal переставали работать на пентиуме. Когда полключался «uses Crt», то он вначале крутил пустой цикл, чтобы определить быстродействие процессора. На пентиумах этот цикл оптимизировался аппаратно и выполнялся за 0 времени. В результате программа вылетала с Division by zero.
В универе до сих пор стоит КУВТ MSX Yamaha не знаю какого бородатого года. Говорят, это неубиваемые машины, где самое крепкое место — клавиатура. На них еще запускается Turbo Pascal 1.0. До сих пор на них учат что-то делать.
В школе мне повезло — в старших классах в наш лицей подогнали полный класс 286 машин. Основными средами разработки были Turbo Pascal 5.5, затем 6.0 с Turbo Vision, и 7.0.
Мне многопоточное программирование напоминает теорию относительности, где понятие «одновременности» и «последовательности событий» не существует. А также квантовую механику, когда два различных потока живут в различных мирах со своим временем (многомировая интерпретация) до того, как произойдет акт их синхронизации (сцепливание, «запутывание»).
Причина, думаю, в том, что сделав в первый раз и получив определенный опыт, в следующий раз хочется нового опыта. Начинаешь задумываться, а как лучше, универсальнее, эстетичнее. Вылезают такие вещи как архитектура приложения, шаблоны, абстракции, фреймворки. А реальный результат затягивается. Затем начинаешь применять различные теории, парадигмы, методологии типа TDD, etc… Результат становится практически недостижим, потому что ориентация уже становится на сам процесс, а не на результат. Потом становится мало языка программирования для элегантного выражения всей полноты мыслей. Наиболее талантливые изобретают свой язык, а другие начинают использовать что-то экзотическое. И под конец заканчиваешь карьеру как полный теоретик парадигм и импотент в продуктивном плане. Отсюда, кстати, идет извечная борьба между тем как «правильно» и тем как «удобно». Излишнее теоретизирование и повсеместное насаждение шаблонов и парадигм — одна из современных проблем IT.
Поэтому главный рецепт — не терять цель из виду, быть ориентированным на результат, а программирование рассматривать как средство достижения результата.
1. Слева панель Unity (Launcher) для того, чтобы у современных широкоформатных мониторов занимать полезную площадь вертикально, а не занимать по горизонтали, как в Гном 2, так нужное в этой плоскости место.
Широкоформатные мониторы нужны исключительно для проигрывания фильмов. У меня на работе обычный Dell повернут на 90 градусов (видеокарта поддерживает повороты), делая разрешение 1024x1280. Я считаю, идеальная пропороция для работы.
2. Кнопки Закрыть, Свернуть расположены слева, чтобы пробег мыши от расположенной слева панели до кнопок был минимален.
При чем тут пробег? Если раньше требовалось небрежное движение «вправо-вверх-до-упора» и клик, то у юнити в кнопку «закрыть» нужно снайперски целиться. Кроме того 90% времени мышь находится именно справа. Да-да, потому-что там скролл. Пробег получается гораздо больше.
3. Глобальное меню помогает сэкономить место за счёт того, что оно общее для всех окон и отображает меню текущего окна. Глобальное меню очень близко к левой части, где расположена панель Ubuntu (Launcher).
Как уже сказали, для неразвернутых окон экономии нет. Кроме того, если на экране умещается несколько окон, то меню работает только для активного окна. Приходится делать дополнительный клик на окне прежде чем появится его меню. Плюс напряг извилины на распознание активного окна.
4. Многих смущает отсутствие так таковой Панели Задач, но значки на панели Unity частично выполняют эту роль, отображая статус «запущенности» в виде белого треугольничка. Ткнув в значок, запущенное приложение выдвигается на передний план. Используя клавиши «Super (она же Meta, Win) + W», все окна отображаются вместе, вне зависимости от виртуальных столов и расположения на них. В таком режиме удобнее «узнать» нужное приложение визуально, чем на Панели Задач. Вспомните, как сильно укорачивается название программы на кнопке Панели Задач, когда запущенных приложений становится много. И переключение по Alt + Tab никто не отменял.
При открытии 10 браузеров треугольника все-равно 3. Логика отдыхает. Ну да ладно. Прочитать в панели задач заголовок окна или его tooltip, а затем кликнуть на него проще, чем кликать в иконку браузера, нажимать магическую комбинацию кнопок и пытаться узнать в очертаниях нечитаемых thumbnail-ов окон нужную страницу.
4a. Насчёт Панели Задач хотелось бы напомнить как происходит переключение мышкой на другую программу. Допустим мышка в центре экрана и нужно мышкой переключиться на другую программу. Мышу ведём вниз или вверх, смотря где Панель Задач. Потом возвращаем мышу в окно появившейся программы для дальнейшей работы. Пробег мыши и работа кисти руки нехилая. А теперь в Unity — мышь на месте, нажимаем Meta + W и не большое перемещение к миниатюре окна программы и программа перед вами. Работаем мышой далее.
Вы опять забываете такую вещь как «прицельная стрельба». Именно она доставляет наибольшие сложности, а отнюдь не пробег. Двиг мышкой до границы экрана — элементарное и не прицельное действие (читай — небрежное). В случае панели задач прицеливание на кнопку окна происходит вдоль границы экрана, то есть на отрезке. Тогда как в юнити — на двумерной плоскости.
5. Используя виртуальные столы, можно разнести приложения по собственным критериям. Переключаясь между столами с помощью «Ctrl + Alt + (стрелки Вверх, Вниз, Влево, Вправо)», можно ускорить свою работу в целом. Перемещать окна между столами можно мышкой в режиме «Super (она же Meta, Win) + S», а можно горячими клавишами «Shift + Ctrl + Alt + (стрелки Вверх, Вниз, Влево, Вправо)».
Единственный критерий — работа вправо, порнушка — влево. В большинстве случаев программа максимизирована на весь экран. Так что разницы большой нет, на каком столе она находится. Кроме того, ни один из производителей коммерческих ОС не ввел виртуальные столы. Видимо, решили, что вполне можно обходиться без них.
6. Клавиша «Ctrl + Alt + Num 5» позволит не только «расхлапывать» на полный экран и «схлапывать» обратно, не сворачивая приложения, но и если нажимать «Ctrl + Alt + Num 5 5 5» изменять размеры приложения, центируя окно одновременно на экране.
Каббала и нумерология — это сложно.
7. Многих бесит исчезнувший Системный Лоток (он же SysTray, Tray, Область уведомлений). Всё решаемо! Команда
gsettings set com.canonical.Unity.Panel systray-whitelist "['all']" и всё «как и былО». Просто помните, что если много значков в Трее, то Глобальное Меню начинает справа поджиматься надвигающими значками и всё!
Прочая магия — тоже не сахар. Если уж производитель решил, что без трея можно обойтись, то пусть мотивирует или предложит схожий концепт. Либо пусть сам и допиливает.
Отдельный неупомянутый здесь ПЦ — это меню юнити. Оно на 100% неюзабельно. Я не помню названия программ. Я лишь знаю, что у меня есть какая-то приблуда для редактирования mp3-тегов. И я ищу ее в разделе «мультимедиа». Кроме того, я хочу видеть ВСЕ то, что у меня установлено в системе. И мне абсолютно нахрен не нужно видеть то, что я еще могу доустановить из репозиториев, потому как я абсолютно не в курсе что делает та или иная неустановленная программа с красивым значком. И устанавливать ее через меню, где я запускаю КОНКРЕТНЫЕ программы, я не собираюсь. Для этого есть Software Center. Если я использую мышку, я не хочу давить кнопки — мне просто неудобно каждый раз таскать руку от мышки к клаве и обратно. И делать сто кликов, чтобы отыскать апликацию в таком удобном меню я тоже не собираюсь. Поэтому мой выбор — cinnamon.
Вопрос — почему? Ответ простой. JBoss ESB одна из самых отстойных, которые я видел. И за годы существования ее не смогли довести до презентабельного уровня. И причина вовсе не в кривых руках и отсутствии разработчиков. Просто ее слишком рано задвинули в коммерческое решение JBoss SOA. А будучи в коммерческом стеке, активная разработка (в т.ч. архитектурные изменения) продукта прекращаются или имеют очень длинный цикл. В результате JBoss ESB не пользовался большой популярность. Поэтому было принято решение взять под крыло одного из лучших конкурентов. Разработка Apache ServiceMix + поддержка от Red Hat сделают продукт популярным в среде крупных компаний.
В распределенных системах вместо synchronized используется понятие транзакции. В J2EE этому соотсветствуют стандарты JTA, XA, JTS, JCA. Насколько я понял, ZooKeeper не интегрируется с JTA. Поэтому не совсем понимаю почему выбор пал на ZooKeeper, а не на стандартные решения типа EHCache или Infinispan (Oracle Coherence трогать не будем)? Работать с блокировками вручную — довольно сложное и ненадежное занятие, приводящее к трудноотлавливаемым ошибкам.
Каждой парадигме — свое целевое использование. Если вспомнить, то ООП стал широко популярным в эру GUI-интерфейсов, где было необходимо создать иерархию однотипных визуальных компонентов в памяти, которые работают в single-thread окружении. И ООП здесь подходит лучше всего.
Но затем встала проблема взаимодействия объектов. Было обнаружено, что массивные операции над состоянием объектов приходится делать через задницу, поскольку каждый объект управлял только своим состоянием. Ввели очень запутанную и трудноотлаживаемую событийную модель, которая сделала невозможным синхронизацию графа и работу с параллельными потоками.
Затем обнаружили, что модель визуальных объектов практически никогда не совпадает с моделью отображаемых сущностей. И придумали MVC (MVP). А программы стали на порядок сложнее, так как приходилось писать леер байндинга между моделью и представлением.
Другая проблема как виртуализация объектов (запись состояния в persistent storage). Поскольку функционал контроллера, сервиса и хранителя состояния был замешан в одном объекте, сериализация и десериализация такого объекта (а тем более графа) стала нетривиальной задачей.
Благодаря этим недостаткам большинство современных фреймворков давно отошло от парадигмы ООП и использует модель, где все операции деляются stateless контроллероп, а состояния хранятся отдельно в простых структурах POJO.
AutoBean не работает с полями, а вместо этого делает враперы. У меня достаточно большая модель, и постоянно растет. Прописывать каждый класс в Factory накладно. К тому же он не решает проблему с десериализацией объектов.
Чтобы десериализовать объект я должен сначала распознать его класс. А для этого нужно его предварительно записать в какую-нибудь хеш-таблицу: Class.forName( «Person» ) в GWT не работает.
RequestFactory служит для т.н. connected-структур — расшареного графа объектов между сервером и клиентом. Это немного не то. Мне нужна была простая сериализация объектов в строку и обратно, причем работающая одинаково как на клиенте, так и на сервере. Со строкой уже можно много что делать: гонять ее туда-сюда по comet-у или вебсокету, засовывать как параметр в GET или POST, использовать ее в нативном JavaScript, сохранять в cookie или persistence storage, и даже передавать между окнами.
Вчера я, наконец, решил эту проблему. Ничего не оставалось как сесть, и написать свою библиотеку. Сегодня только залил. Вот, может кому и пригодится: code.google.com/p/gwt-streamer/
Основной бич GWT — это сериализация POJO-структур. Сделана она отвратительна, а точнее не сделана вообще. GWT-RPC в счет не берем, поскольку он предлагает сугубо внутреннюю имплементацию служащую лишь для вызовов. Поэтому ни клонировать, ни «послать-как-строку» при помощи него нельзя. И что странно, до сих пор практически нет нормальных библиотек, делающих простой маршаллинг/демаршаллинг объектов GWT.
Это да, только в данном случае мерялось скорей производительность создания коннекшнов, а не их работы. Создание коннекшна — тяжелая операция как для ОС, так и для платформы. Если создавать коннекшны неспеша, то Java, например, легко может держать и более 10к коннекшнов. Реальная проблема возникает при числе коннекшнов близком 32767.
> Во время бенчмарка каждую миллисекунду запускается новый клиент.
Вот здесь основной затык. Реально пользователи не будут коннектиться каждую миллисекунду. Если создавать коннекшны с бОльшим интервалом, например втечении пяти-десяти минут, то количество коннекшнов будет гораздо больше.
Сценарий 2 (продолжение)
Резкое расслоение уровня доходов приведет к четкому формированию двух классов: «владельцев», получающих доход по праву владения и «обслуги», вынужденной продавать себя и свой труд. Для «обслуги» населения жизнь внутри мегагородов становится не по карману, и они постеменно смещаются на периферию. Мегагорода обрастают большим числом городов-спутников, куда переносится все производство и обслуживающие сервисы, и где сконцентрировано основное население региона. Внутри мегаполисов концентрируются исключительно транснациональные корпорации, финансовые структуры и районы с особняками. Мегагорода ограждаются от периферии барьерами, въезд за которые возможен только по визе или спецпропуску. Наоборот, между мегагородами отсутствуют всякие ограничения на передвижение и торговлю. Постепенно внутри класса обслуги также происходит расслоение на тех, кто работает на мегаполис (относительно высокий доход), и тех, чей источник доходов находится внутри периферии. В итоге периферия разделяется на «ближнюю» и «дальнюю». Для бОльшего экономического контроля над периферией регион вводит собственную валюту.
В школе мне повезло — в старших классах в наш лицей подогнали полный класс 286 машин. Основными средами разработки были Turbo Pascal 5.5, затем 6.0 с Turbo Vision, и 7.0.
Поэтому главный рецепт — не терять цель из виду, быть ориентированным на результат, а программирование рассматривать как средство достижения результата.
ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B8%D0%BE%D0%BA%D1%80%D0%B0%D1%82%D0%B8%D1%8F
Широкоформатные мониторы нужны исключительно для проигрывания фильмов. У меня на работе обычный Dell повернут на 90 градусов (видеокарта поддерживает повороты), делая разрешение 1024x1280. Я считаю, идеальная пропороция для работы.
2. Кнопки Закрыть, Свернуть расположены слева, чтобы пробег мыши от расположенной слева панели до кнопок был минимален.
При чем тут пробег? Если раньше требовалось небрежное движение «вправо-вверх-до-упора» и клик, то у юнити в кнопку «закрыть» нужно снайперски целиться. Кроме того 90% времени мышь находится именно справа. Да-да, потому-что там скролл. Пробег получается гораздо больше.
3. Глобальное меню помогает сэкономить место за счёт того, что оно общее для всех окон и отображает меню текущего окна. Глобальное меню очень близко к левой части, где расположена панель Ubuntu (Launcher).
Как уже сказали, для неразвернутых окон экономии нет. Кроме того, если на экране умещается несколько окон, то меню работает только для активного окна. Приходится делать дополнительный клик на окне прежде чем появится его меню. Плюс напряг извилины на распознание активного окна.
4. Многих смущает отсутствие так таковой Панели Задач, но значки на панели Unity частично выполняют эту роль, отображая статус «запущенности» в виде белого треугольничка. Ткнув в значок, запущенное приложение выдвигается на передний план. Используя клавиши «Super (она же Meta, Win) + W», все окна отображаются вместе, вне зависимости от виртуальных столов и расположения на них. В таком режиме удобнее «узнать» нужное приложение визуально, чем на Панели Задач. Вспомните, как сильно укорачивается название программы на кнопке Панели Задач, когда запущенных приложений становится много. И переключение по Alt + Tab никто не отменял.
При открытии 10 браузеров треугольника все-равно 3. Логика отдыхает. Ну да ладно. Прочитать в панели задач заголовок окна или его tooltip, а затем кликнуть на него проще, чем кликать в иконку браузера, нажимать магическую комбинацию кнопок и пытаться узнать в очертаниях нечитаемых thumbnail-ов окон нужную страницу.
4a. Насчёт Панели Задач хотелось бы напомнить как происходит переключение мышкой на другую программу. Допустим мышка в центре экрана и нужно мышкой переключиться на другую программу. Мышу ведём вниз или вверх, смотря где Панель Задач. Потом возвращаем мышу в окно появившейся программы для дальнейшей работы. Пробег мыши и работа кисти руки нехилая. А теперь в Unity — мышь на месте, нажимаем Meta + W и не большое перемещение к миниатюре окна программы и программа перед вами. Работаем мышой далее.
Вы опять забываете такую вещь как «прицельная стрельба». Именно она доставляет наибольшие сложности, а отнюдь не пробег. Двиг мышкой до границы экрана — элементарное и не прицельное действие (читай — небрежное). В случае панели задач прицеливание на кнопку окна происходит вдоль границы экрана, то есть на отрезке. Тогда как в юнити — на двумерной плоскости.
5. Используя виртуальные столы, можно разнести приложения по собственным критериям. Переключаясь между столами с помощью «Ctrl + Alt + (стрелки Вверх, Вниз, Влево, Вправо)», можно ускорить свою работу в целом. Перемещать окна между столами можно мышкой в режиме «Super (она же Meta, Win) + S», а можно горячими клавишами «Shift + Ctrl + Alt + (стрелки Вверх, Вниз, Влево, Вправо)».
Единственный критерий — работа вправо, порнушка — влево. В большинстве случаев программа максимизирована на весь экран. Так что разницы большой нет, на каком столе она находится. Кроме того, ни один из производителей коммерческих ОС не ввел виртуальные столы. Видимо, решили, что вполне можно обходиться без них.
6. Клавиша «Ctrl + Alt + Num 5» позволит не только «расхлапывать» на полный экран и «схлапывать» обратно, не сворачивая приложения, но и если нажимать «Ctrl + Alt + Num 5 5 5» изменять размеры приложения, центируя окно одновременно на экране.
Каббала и нумерология — это сложно.
7. Многих бесит исчезнувший Системный Лоток (он же SysTray, Tray, Область уведомлений). Всё решаемо! Команда
gsettings set com.canonical.Unity.Panel systray-whitelist "['all']" и всё «как и былО». Просто помните, что если много значков в Трее, то Глобальное Меню начинает справа поджиматься надвигающими значками и всё!
Прочая магия — тоже не сахар. Если уж производитель решил, что без трея можно обойтись, то пусть мотивирует или предложит схожий концепт. Либо пусть сам и допиливает.
Отдельный неупомянутый здесь ПЦ — это меню юнити. Оно на 100% неюзабельно. Я не помню названия программ. Я лишь знаю, что у меня есть какая-то приблуда для редактирования mp3-тегов. И я ищу ее в разделе «мультимедиа». Кроме того, я хочу видеть ВСЕ то, что у меня установлено в системе. И мне абсолютно нахрен не нужно видеть то, что я еще могу доустановить из репозиториев, потому как я абсолютно не в курсе что делает та или иная неустановленная программа с красивым значком. И устанавливать ее через меню, где я запускаю КОНКРЕТНЫЕ программы, я не собираюсь. Для этого есть Software Center. Если я использую мышку, я не хочу давить кнопки — мне просто неудобно каждый раз таскать руку от мышки к клаве и обратно. И делать сто кликов, чтобы отыскать апликацию в таком удобном меню я тоже не собираюсь. Поэтому мой выбор — cinnamon.
Но затем встала проблема взаимодействия объектов. Было обнаружено, что массивные операции над состоянием объектов приходится делать через задницу, поскольку каждый объект управлял только своим состоянием. Ввели очень запутанную и трудноотлаживаемую событийную модель, которая сделала невозможным синхронизацию графа и работу с параллельными потоками.
Затем обнаружили, что модель визуальных объектов практически никогда не совпадает с моделью отображаемых сущностей. И придумали MVC (MVP). А программы стали на порядок сложнее, так как приходилось писать леер байндинга между моделью и представлением.
Другая проблема как виртуализация объектов (запись состояния в persistent storage). Поскольку функционал контроллера, сервиса и хранителя состояния был замешан в одном объекте, сериализация и десериализация такого объекта (а тем более графа) стала нетривиальной задачей.
Благодаря этим недостаткам большинство современных фреймворков давно отошло от парадигмы ООП и использует модель, где все операции деляются stateless контроллероп, а состояния хранятся отдельно в простых структурах POJO.
Чтобы десериализовать объект я должен сначала распознать его класс. А для этого нужно его предварительно записать в какую-нибудь хеш-таблицу: Class.forName( «Person» ) в GWT не работает.
Вчера я, наконец, решил эту проблему. Ничего не оставалось как сесть, и написать свою библиотеку. Сегодня только залил. Вот, может кому и пригодится: code.google.com/p/gwt-streamer/
Основной бич GWT — это сериализация POJO-структур. Сделана она отвратительна, а точнее не сделана вообще. GWT-RPC в счет не берем, поскольку он предлагает сугубо внутреннюю имплементацию служащую лишь для вызовов. Поэтому ни клонировать, ни «послать-как-строку» при помощи него нельзя. И что странно, до сих пор практически нет нормальных библиотек, делающих простой маршаллинг/демаршаллинг объектов GWT.
Всем, кому знакома проблема, рекомендую фреймворк JBoss Errai.
Вот здесь основной затык. Реально пользователи не будут коннектиться каждую миллисекунду. Если создавать коннекшны с бОльшим интервалом, например втечении пяти-десяти минут, то количество коннекшнов будет гораздо больше.