2. Не нравятся они мне. Мне нравится свинговый GroupLayout, все остальные не так мощны.
Мне тоже нравился вначале GroupLayout. Но вообще, там внутри концепция мозгоразрывная. А единственный вменяемый дизайнер из Netbeans тоже имеет ряд глюков и иногда перекашивает весь layout, и ничего не поделаешь. Так что теперь склоняюсь к GridBagLayout. Хотя, layout'ы в AWT/Swing кривоваты. Например, у GridBagLayout нельзя задавать промежутки между ячейками (insets — это несколько другое).
Вот что вспомнилось навскидку:
1. Хотя бы своим классом SWT с кучей констант.
2. А есть ли в SWT вообще понятие baseline (вроде бы у меня с этим какие-то проблемы возникали)?
3. Таблица в SWT не менее убогая, чем в Swing.
4. Загрузить иконку из ресурсов — нужен дополнительный велосипедный костыль.
5. Неудобная обработка событий клавиатуры. Нет аналога event bubbling из DOM Events, события обрабатываются только тем контролом, который в фокусе.
А никаких. Взять и застрелиться. И проклинать тех, кто делал SWT и Swing. Или написать свою мегабиблиотеку, без всех недостатков. Но последнее никому не нужно, ибо миллионы индусов уже привыкли писать говнокод и со Swing'ом. А ещё можно писать веб-приложения, где придётся столкнуться либо со всеми прелестями JSF (вторая версия в принципе такое же говно, как и первая), либо со всеми прелестями HTML. Ох, зря я в программисты пошёл…
6. Для того, чтобы дать пользователю возможность выбирать даты есть отличный компонент jcalendar
Он не отличный. JDateChooser меня разочаровал следующим:
1. не поддерживает выравнивание по базовой линии (baseline)
2. есть проблемы с обнулением даты внутри него
3. нет возможности дать пользователю ввести 1.02.12 и чтобы JDateChooser интерпретировал это как 1.02.2012; такое можно вылечить самому, но это дополнительная подпорка.
4. плохо дружит с различными темами; в частности, у меня были проблемы с Nimbus и substance.
9. Для того, чтобы изменить компоненты swing из другого потока нужно использовать посредника:
Есть базовый механизм запуска произвольного кода в потоке GUI — invokeLater. А всякие SwingWorker'ы — это уже механизмы поверх.
В целом разработка под swing парадовала обилием документации и примеров на все случаи жизни. Если интересно могу еще в том же духе поподробней рассказать про фишки JTable.
В целом Swing разочаровывает. Такое ощущение, что его писали какие-то стоумовые ребята, которые сели, выдумали концепцию, а потом всё это им осточертело на стадии реализации и они сделали всё тяп-ляп, для галочки. А местами просто ужасно перемудрили (например, как с Action'ами и привязкой их к кнопкам и клавиатуре). Про JTable я вообще молчу — на каждую тривиальную штуку приходится городить серьёзные костыли. Ну и сама Java местами подводит — например, в языке нет механизма для лаконичной подписки на события. Или вот swing делался в те времена, когда ещё не было enum'ов, потому всякие флажки и перечисления сделаны числовыми константами — это просто ужасно.
Pascal конечно — он и задумывался как язык для обучения…
… 40 лет назад. А 20 лет назад для этого задумали другой язык — Python. И в нём есть плюшечки вроде массивов, размер которых можно задать за пределами compile time, алгоритмов (скажем, сортировки), которые не надо реализовывать для каждого типа данных (шаблоны в C++ и generics в Java для деток неподъёмны) и т.п.
Сдаётся мне, всё-таки есть проблемы с методикой тестирования. По всем тестам, которые я видел, у Ruby и JRuby по разным тестам примерно сопоставимые результаты. Но так, чтобы JRuby был в 10 раз медленее — это что-то совсем новое. Что там внутри WEBrick — понятия не имею. Может, что-то дёргается из того, что плохо реализовано в JRuby. Может, на каждый чих поднимается новый процесс c JRuby (как известно, для JVM это тяжёлое испытание).
Сервер приложений — это которому шлют RPC-запросы (например, SOAP, XML-RPC или JSON-RPC), он их выполняет и шлёт обратно ответ. Когда серверу возвращает HTML для браузера, это уже веб-сервер. Насчёт многих не знаю, а вот контейнеры сервлетов любые параметры преобразуют в массивы.
Ну скажем так. В классической механике уравнение движения тоже «выдумано», кстати, как и понятие энергии. Энергию, в отличие от массы, например, не пощупаешь. Зато очень удобно описывать поведение систем. А для квантовой механики сделали аналогичные уравнения, предельным переходом.
Просто физики напрасно выдают ограниченную точность измерений ЭМ волнами за фундаментальную неопределённость
Ну вот не знаю. В своё время в универе мы вводили волновую функцию и рассматривали операторы над ней. Так вот неопределённость мы вывели чисто математически в виде коммутатора операторов. Всё было абсолютно строго, без дополнительных допущений. Сама же волновая функция — это тоже не новая на тот момент (1920-е годы) штука. Скажем, механические явления можно записывать с помощью функций Лагранжа и Гамильтона. Так вот оно очень удобно, когда рассматриваются статистические ансамбли, ну там какой-нибудь газ. В квантовой механике сделали точно то же самое, но с прицелом на квантовые свойства. Всё выглядело очень строго и фундаментально. Так что где физики чего выдумали, я не заметил.
Не дождётся. Ну вот есть два сцеплённых фотона, которые пока никто не измерял, т.е. каждый из них находится в неопределённом состоянии. Вы думаете, воздействуете на первый, а второй примет противоположное состояние тем самым передав информацию? А вот и нет. Чтобы получателю пришла информация, он должен измерять состояние второго фотона. А тем самым он просто устранит неопределённость и передающая сторона внезапно застанет фотон в одном из состояний. Можно возразить и предложить получателю мониторить свой фотон гарантированно позже, чем отправитель понаблюдает свой фотон. Но тогда уже встаёт проблема синхронизации часов, т.е. опять передача информации, об этом уже много написано.
А вообще, всё гораздо проще обламывается. Наблюдать фотон мы можем, а вот наблюдать так, чтобы он оказался в нужном нам состоянии — нет.
выполняющий 3 INNER JOIN'а на таблицы, размеры которых впечатляли. Каждая таблица в среднем содержала 40 000 000 миллионов записей. Получается, что временная таблица состояла бы из 4*4*4*10^21 = 64*10^21 записей
O_O А точно никак не обойтись без этих INNER JOIN'ов? Тем более, кто сказал, что JOIN'ы выполняются путём создания декартова произведения и полного просмотра получившейся таблицы? Всё сильно зависит от наличия индексов и типа отношений.
Итак, предположим, что нам необходимо сделать INNER JOIN на 3 таблицы, а затем задать условие «столбец х в диапазоне между 10 и 20». Причём столбец х не имеет индекса.
Ну так а добавить индекс? Или там так часто делаются вставки/обновления? Тогда непонятно, почему по такой нагруженной таблице строятся отчёты.
Берем таблицу с этим самым столбцом и применяем на ней бинарный поиск, для поиска диапазона первичных ключей, удовлетворяющих условию 10<=x<=20
Т.е. правильно ли я понимаю, что значения в столбце x монотонно возрастают, т.е. для любых строк a и b верно: a.id > b.id => a.x > b.x? Но в любом случае, бинарный поиск — это поиск по индексированному списку, а не по таблице. Индексированный список, в отличие от таблицы, не содержит «дырок», так что в нём не стоит проблемы «а что делать, если при очередном разделении пополам мы не нашли элемент с индексом k».
Вообще, я бы делал так:
1. Если каким-то образом удалось определить, что один из потоков «подвис», прибиваем всё приложение. В общем случае, как уже было сказано выше, нельзя определить, есть ли зависший поток, так что, может быть, спасёт какая-нибудь эвристика.
2. Чтобы приложение всё же продолжало работать дальше, делаем guard-процесс.
Чаще всего приложение — это какой-нибудь сервер, в котором потоки обслуживают входящие запросы. В этом случае совсем хорошо было бы сделать так. Рабочий процесс может с guard-процессом общаться каким-нибудь средством IPC (те же сокеты, например). Если рабочий процесс обнаруживает внутри себя зависший поток, он предпринимает следующие действия:
1. Отдаёт guard-процессу запустить и проинициализировать новый процесс, но пока не слушать порт (он ведь слушается рабочим процессом).
2. Освобождает порт и закрывает все соединения.
3. Отдаёт guard-процессу команду о том, что новый процесс может отныне слушать порт.
4. Рабочий процесс прибивает себя.
Так снижается время простоя сервера. Правда, получится, что одновременно будет запущено 3 процесса (из них 2 — рабочих), причём новый рабочий процесс вынужден будет выполнять, возможно дорогую, инициализацию в то время, пока старый рабочий процесс отъедает много ресурсов на зависшем потоке.
Сложно? А что хотели? Thread.stop() действительно небезопасен. Ведь все блокировки слетают и приложение остаётся в неконсистентном состоянии. Дальшейшее его повидение может быть непредсказуемым.
А плагины вот так просто тоже не ставятся на продуктивный сервер. Они должны быть «из доверенных источников». Да и вообще, что значит плагин для сервера? Кто будет делать запросы к этому плагину? Тогда нужно, чтобы и клиент знал про этот плагин и умел им пользоваться.
Аналогично, привык «правильно» всё произносить. Но некоторые названия всё-таки ставят в тупик. Например, GWT или IEEE. Потому произношу неправильно, как проще для русского (ГВТ, И-три-Е). Ну потому что реально неудобно их по-английски произносить. С ходу не вспомню, но ещё несколько таких точно было.
Подобные задачки решал ещё в 7-м классе. Единственное, что тогда это были полноценные программки, а не stateless-функции. Полагаю, что это для первичного отсева совсем уж никаких кандидатов? Я, помнится, на текущее место работы тоже делал детское задание — клиент-серверное приложение, где клиент шлёт на сервер простенькие XML-файлы, а сервер просто вытаскивал из них пару полей и записывал в PostgreSQL. Как мне потом объяснили, это чтобы не тратить время на собеседования с совсем уж откровенной школотой.
Не, я про то, что Gnome 3 заставил пересесть меня на KDE и если раньше я для запуска проигрывателя набирал exaile, то теперь — clementine. А так, clementine и есть форк Amarok 1.4
1. Хотя бы своим классом SWT с кучей констант.
2. А есть ли в SWT вообще понятие baseline (вроде бы у меня с этим какие-то проблемы возникали)?
3. Таблица в SWT не менее убогая, чем в Swing.
4. Загрузить иконку из ресурсов — нужен дополнительный велосипедный костыль.
5. Неудобная обработка событий клавиатуры. Нет аналога event bubbling из DOM Events, события обрабатываются только тем контролом, который в фокусе.
Он не отличный. JDateChooser меня разочаровал следующим:
1. не поддерживает выравнивание по базовой линии (baseline)
2. есть проблемы с обнулением даты внутри него
3. нет возможности дать пользователю ввести 1.02.12 и чтобы JDateChooser интерпретировал это как 1.02.2012; такое можно вылечить самому, но это дополнительная подпорка.
4. плохо дружит с различными темами; в частности, у меня были проблемы с Nimbus и substance.
Есть базовый механизм запуска произвольного кода в потоке GUI — invokeLater. А всякие SwingWorker'ы — это уже механизмы поверх.
В целом Swing разочаровывает. Такое ощущение, что его писали какие-то стоумовые ребята, которые сели, выдумали концепцию, а потом всё это им осточертело на стадии реализации и они сделали всё тяп-ляп, для галочки. А местами просто ужасно перемудрили (например, как с Action'ами и привязкой их к кнопкам и клавиатуре). Про JTable я вообще молчу — на каждую тривиальную штуку приходится городить серьёзные костыли. Ну и сама Java местами подводит — например, в языке нет механизма для лаконичной подписки на события. Или вот swing делался в те времена, когда ещё не было enum'ов, потому всякие флажки и перечисления сделаны числовыми константами — это просто ужасно.
А зачем такое извращение? И вообще, justify должен вымереть, пока браузеры не научатся делать его, как это делает TeX.
… 40 лет назад. А 20 лет назад для этого задумали другой язык — Python. И в нём есть плюшечки вроде массивов, размер которых можно задать за пределами compile time, алгоритмов (скажем, сортировки), которые не надо реализовывать для каждого типа данных (шаблоны в C++ и generics в Java для деток неподъёмны) и т.п.
Ну вот не знаю. В своё время в универе мы вводили волновую функцию и рассматривали операторы над ней. Так вот неопределённость мы вывели чисто математически в виде коммутатора операторов. Всё было абсолютно строго, без дополнительных допущений. Сама же волновая функция — это тоже не новая на тот момент (1920-е годы) штука. Скажем, механические явления можно записывать с помощью функций Лагранжа и Гамильтона. Так вот оно очень удобно, когда рассматриваются статистические ансамбли, ну там какой-нибудь газ. В квантовой механике сделали точно то же самое, но с прицелом на квантовые свойства. Всё выглядело очень строго и фундаментально. Так что где физики чего выдумали, я не заметил.
Не дождётся. Ну вот есть два сцеплённых фотона, которые пока никто не измерял, т.е. каждый из них находится в неопределённом состоянии. Вы думаете, воздействуете на первый, а второй примет противоположное состояние тем самым передав информацию? А вот и нет. Чтобы получателю пришла информация, он должен измерять состояние второго фотона. А тем самым он просто устранит неопределённость и передающая сторона внезапно застанет фотон в одном из состояний. Можно возразить и предложить получателю мониторить свой фотон гарантированно позже, чем отправитель понаблюдает свой фотон. Но тогда уже встаёт проблема синхронизации часов, т.е. опять передача информации, об этом уже много написано.
А вообще, всё гораздо проще обламывается. Наблюдать фотон мы можем, а вот наблюдать так, чтобы он оказался в нужном нам состоянии — нет.
O_O А точно никак не обойтись без этих INNER JOIN'ов? Тем более, кто сказал, что JOIN'ы выполняются путём создания декартова произведения и полного просмотра получившейся таблицы? Всё сильно зависит от наличия индексов и типа отношений.
Ну так а добавить индекс? Или там так часто делаются вставки/обновления? Тогда непонятно, почему по такой нагруженной таблице строятся отчёты.
Т.е. правильно ли я понимаю, что значения в столбце x монотонно возрастают, т.е. для любых строк a и b верно: a.id > b.id => a.x > b.x? Но в любом случае, бинарный поиск — это поиск по индексированному списку, а не по таблице. Индексированный список, в отличие от таблицы, не содержит «дырок», так что в нём не стоит проблемы «а что делать, если при очередном разделении пополам мы не нашли элемент с индексом k».
1. Если каким-то образом удалось определить, что один из потоков «подвис», прибиваем всё приложение. В общем случае, как уже было сказано выше, нельзя определить, есть ли зависший поток, так что, может быть, спасёт какая-нибудь эвристика.
2. Чтобы приложение всё же продолжало работать дальше, делаем guard-процесс.
Чаще всего приложение — это какой-нибудь сервер, в котором потоки обслуживают входящие запросы. В этом случае совсем хорошо было бы сделать так. Рабочий процесс может с guard-процессом общаться каким-нибудь средством IPC (те же сокеты, например). Если рабочий процесс обнаруживает внутри себя зависший поток, он предпринимает следующие действия:
1. Отдаёт guard-процессу запустить и проинициализировать новый процесс, но пока не слушать порт (он ведь слушается рабочим процессом).
2. Освобождает порт и закрывает все соединения.
3. Отдаёт guard-процессу команду о том, что новый процесс может отныне слушать порт.
4. Рабочий процесс прибивает себя.
Так снижается время простоя сервера. Правда, получится, что одновременно будет запущено 3 процесса (из них 2 — рабочих), причём новый рабочий процесс вынужден будет выполнять, возможно дорогую, инициализацию в то время, пока старый рабочий процесс отъедает много ресурсов на зависшем потоке.
Сложно? А что хотели? Thread.stop() действительно небезопасен. Ведь все блокировки слетают и приложение остаётся в неконсистентном состоянии. Дальшейшее его повидение может быть непредсказуемым.
А плагины вот так просто тоже не ставятся на продуктивный сервер. Они должны быть «из доверенных источников». Да и вообще, что значит плагин для сервера? Кто будет делать запросы к этому плагину? Тогда нужно, чтобы и клиент знал про этот плагин и умел им пользоваться.