Меня очень огорчают программисты, которые не знают, что такое DI, IoC-containers, method interceptions, обычно это программисты C++ и прочие Си-парни, с квалификацией битомешателей в кодинге и с квалификацией ниже плинтуса в промышленной разработке.
Полностью поддерживаю! А ещё меня огорчают программисты, который не различают контекстно-зависимой и контекстно-свободной грамматик, которые удивлённо мигают, видя запись O(n^3) или не понимают, что типизация бывает статической и динамической а так же строгой и нестрогой.
Образ на то и неочевидный, что он неочевиден и для меня. Ну я могу начать последовательность, но до x86 она не доходит. В общем, пишу на Java EE и в БД лезу через JPA. Порой бывает так, что какая-то штука начинает тормозить и выясняется, что ORM выдаёт тормозные запросы. Приходится специально ковырять JPQL и задавать хинты (ORM-специфичные, EclipseLink) так, чтобы получать лучший SQL. Порой вообще приходится выкидывать ORM и работать напрямую через JDBC. Далее, проламывается и просто SQL, ибо запрос тормозит, и непонятно почему. Приходится выполнять EXPLAIN SELECT и думать, почему же планировщик запросов конкретной СУБД (PostgreSQL) не хочет вести себя так, как мне хочется. Ну самый нижний уровень — приходится иногда таблицу проектировать с учётом того, как работает СУБД. Соответственно, тонко настраивать СУБД, планировать периодичность запуска VACUUM и т.п. Думаю, если бы объёмы данных были больше, то пришлось бы ещё больше лезть «вниз», но пока не приходилось.
Вот примерно в этом ключе говорят наши бизнес-аналитики, когда спрашиваешь их как они до жизни такой дошли. Потому, говорят, они бизнес-аналитики, а я простой Java-кодер. Впрочем, они там лет на 10-15 старше.
Нет у нас СУБД, пользуемся только сторонними сервисами. Каким образом, ь знания об организации и работы с памятью нам пригодятся?
Да порой самым неочевидным образом. Порой просто легче принять верное решение, обладая опытом в разных областях. А если, скажем, приложение становится популярным и им начинают пользоваться миллионы пользователей, то остро встаёт вопрос производительности. А тут уже все методы хороши (в том числе и оптимизация на уровне железа). И не надо говорить про дешевизну железа. Железо — это не что-то, что поставили и работает, его тоже надо обслуживать.
Если честно, меня обидели слова «Меня вообще очень огорчают программисты, которые не знают как работает машина, обычно это программисты Java и прочие php-парни, с квалификацией ниже плинтуса»,
Пожимаю плечами. Может, надо просто ироничнее относиться к себе. Я вот тоже пишу на Java и PHP. И что с того?
Я не считаю свою квалификацию ниже плинтуса, так как решаю повседневные задачи, за которые получаю деньги, и решение той или иной задачи приносит пользу заказчику
Ну всегда полезно взглянуть на себя с другой стороны. Поставить под сомнение свою квалификацию.
Тогда за, что мне платят деньги?
А вот это уж точно никак не показывает чью-либо квалификацию.
Я не универсал. Я глубоко знаю только Java. Но поверхностно интересовался многим. В том числе когда-то под DOS писал программки, переходящие в защищённый режим, включавщие режим SVGA и через VESA что-то красивое рисующие на экране. Вроде с тех пор не забылись хотя бы в общих чертах принципы работы архитектуры x86. А потом ещё алгоритмы, которые мы проходили в курсе «численные методы» реализовывал на Haskell. Моего опыта не хватило бы, чтобы написать драйвер видюхи для Linux или CAS — я не универсал, а Java-программист. Но тем не менее, я считаю, что получил полезный опыт, который полезен мне и как Java-программисту.
Ну как минимум вопрос об организации памяти в конкретной взятой системе — это пример решения задачи. Обладая знаниями о том, как принято решать задачи из различных областей, гораздо проще решать свои повседневные задачи. Это называется опыт. И, кстати, иногда всё-таки нужно понимать, как работает физика. Например, когда Java-программа, выдающая отчёты по продажам, должна так же научиться печатать стикеры на товары. И тут начинается головная боль с COM-портом, драйверами для принтера этикеток, JNI и прочее. Ну или вот современные СУБД очень и очень отталкиваются от физической организации диска, «пробивая» такую абстракцию, как «файловая система».
Никто не заставляет при разработке бухгалтерской программы заниматься организацией памяти. Но вот как-то получается, что те, кто способен хорошо оптимизировать расчёт счетов-фактур, почему-то ещё знают, как работает железо. Интересная корреляция, правда?
Помимо просто знания Java или PHP, программисту не мешает хотя бы приблизительно ознакомиться с тем, как работает железо, почитать Кнута, SICP, порешать олимпиадные задачи, написать драйвер и т.д.
К сожалению, тут вопрос больше не к разработчикам приложений, а к разработчикам swing. Он изначально задумывался как ненативно выглядящий. И «нативные» темы всё же немного отличаются от того, как реально выглядят другие приложения в ОС. И если в случае с Windows ещё терпимо, то GTKLookAndFeel — то ещё глючное тормозное убожество. И сколько бы они не подгоняли тему, рендерер шрифтов так и остаётся велосипедным. Он мало того, что просто отличатся, так по мне ещё и во много раз хуже оригинальных рендереров (особенно, в Linux).
MySQL тоже некорректно переводить как my structured query language, ибо MySQL -это СУБД, а не язык. Вообще, MySQL — это название продукта, а не аббревиатура, которую можно расшифровать.
XML-синтаксис «не пошел»… потому что он просто не применим к вебу, в 99% случаев не дает никаких плюшек, но при этом замусоривает код большим количеством цифрового шума и менее адекватен поставленной задаче, чем HTML.
Ага, этому и посвящена достаточна большая часть Вашей статьи. Вот только чтобы такие вещи утверждать, мало их написать на заборе. И ниже Вы начинаете пояснять, почему так. Так вот моё утверждение: все эти аргументы несостоятельны. Потому что банально неверны. Почему неверны, можно понять, разобравшись путём с XML. В принципе, я в первом комментарии кратко объяснил, что к чему. Но Вы-то ярый борец с «XML-сектой», потому, видимо, разбираться с XML — ниже Вашего достоинства.
Почему я должен спорить с вами об XML схемах? К вебу они не имеют ну совсем никакого отношения, и поэтому в моей статье про них ничего нет.
Ну какой-то мифический получается веб. В вебе что используется? HTML/XHTML. Формально их синтаксис описать надо? Надо. А это и делается с помощью DTD или более мощного средства, существующего в XML-мире — XML-схем. Ну вот я привёл кусок такого формального описания. Можно было бы и кусок DTD скопипастить. Или вообще кусок текста из стандарта. Однако, текст небезгрешен, его можно трактовать по-всякому, не в пример формальному описанию.
Вы предлагаете «вообще не использовать PHP» и «взять шаблонизатор», хотя PHP и есть в чистом виде шаблонизатор, прокладка между базой данных и веб-браузером.
PHP — не лучший шаблонизатор. Я бы предпочёл apache velicity, razor или самописный. Некоторые суровые парни высказались бы в пользу XSLT. Но это неважно. А важно то, что при прямом использовании проставлять кавычки и закрывающие теги в PHP не сильно страшно, вопреки Вашему ещё одному аргументу против XML-синтаксиса HTML (или XHTML, что верно для HTML 4).
Да при чём тут XML-фанатизм? Как раз я-то разбираюсь в чисто технических вещах и у меня есть строгие доводы в пользу XML. А вот Ваша статья как раз демонстрирует фанатичную любовь в SGML-синтаксису HTML, подкрепляемому неверными или сомнительными доводами. Вот этот Ваш ответ, извините, — пустая демагогия.
Почему XML-синтаксис не прижился? Потому т.н. «веб-программисты» не осилили. Потому что W3C занимались синтаксисом, а не пытались сделать что-то для улучшения семантики HTML. Кстати, HTML5 ничего не говорит о синтаксисе. Точнее, там он присутствует, но описание HTML-элементов даётся в нейтральной манере, чтобы можно было семантику завернуть в любой синтаксис. Кстати, если глянуть на XHTML 1.0, то можно увидеть, что по сути это такой же XML-синтаксис для HTML 4. Так что противопоставлять XHML и HTML5 попросту неверно, т.к. это всё равно, что противопоставлять HTML 4 и HTML5 — разумеется, второй лучше. А почему XHTML 2 так и не был готов? А не потому, что разработчики принадлежали к сектам семантистов и XML-истов, а потому, что были банальными бюрократами.
Автор статьи совершенно не разбирается в предмете. Он не понимает, что такое SGML и XML, что такое их приложение, что такое правильно построенный (well-formed) и валидный XML-документ. Он даже XML-элементы называет тегами, хотя при описании семантики это неверно (даже стандарт HTML5 всячески пытается уйти от текстового представления документа с его тегами). Ну или вот прекрасное
В xhtml же технически возможен (и с точки зрения XML даже валиден!) вот такой код:
текст ячейки текст между ячейками, отображайте где хотите
хотя если почитать XHTML In XML Schema, то увидим такое
Однако, подобное поведение — отказ от обработки всего документа при обнаружении любой ошибки — абсолютно неприемлемо для веба, где большую часть контента создают отнюдь не программы и даже не верстальщики, а сайт-менеджеры, писатели, блоггеры и, зачастую, рядовые посетители сайтов
программы этот контент нам презентуют во вменяемом виде. Конечно, кто-то до сих пор пишет HTML в блокнотике. Но вообще, обычно берут CMS, у которой есть либо WYSIWYG-редактор, либо язык вики-разметки. Так вот в любом случае, текст, введённый пользователем, нужно тщательно отпарсить во внутреннее представления и потом по внутреннему представлению генерить (X)HTML, подставляя, где нужно, теги (в том числе и закрывающие) и экранируя текст. Если всего этого CMS делать не умеет, то грош ей цена
Постоянные переключения синтаксиса в одном файле ни к чему хорошему не приводят, глаз программиста замыливается, и становятся возможными достаточно трудно вылавливаемые синтаксические ошибки.
Ну во-первых, не надо уж использовать упомянутый чуть выше PHP (впрочем, лучше вообще его не использовать) не по назначению. Может, не следует генерить (X)HTML из кода, а взять шаблонизатор? Тогда таких проблем не возникнет.
Насколько я знаю, SAP написан на java, в качестве БД может использовать и oracle, и db2 и вроде бы даже mssql.
На сколько я знаю, в SAP есть какие-то штуки, написанные на Java. А в общем случае так нельзя сказать. Я вообще на вопрос, на чём написан SAP, получил ответ «на ABAP». Наверное, это недалеко от истины. И, кстати, вроде бы есть какой-то форк MySQL специально для SAP и он даже официально поддерживается.
Как-как. Делается обычный класс. Даже не вложенный (потому что inner classes никак особо не поддерживаются в JVM, просто используется соглашение на именование класса и его полей). Переменные, которые замыкание вытаскивает из вышестоящего контекста, преобразуются в поля данного класса. Внутри замыкания при обращении к этим переменным реально вытягиваются значения полей. При создании замыкания после собственно создания экземпляра класса его полям дополнительно присваиваются значения переменных, выхваченных из контекста. Т.е. это даже не фича JVM.
Чуть ли не самое лучшее описание байткода JVM, которые я видел, содержится в документации по ASM (http://download.forge.objectweb.org/asm/asm-guide.pdf). Кстати, эта библиотека, на мой взгляд, на порядок лучше BCEL, особенно, если нужно просто сгенерить класс из пустого места (а не трансформировать имеющийся). Кроме того, в ASM есть свой валидатор байткода, поддерживающий все фичи последних JVM. В BCEL тоже есть, но там поддерживается только несколько устаревшная спецификация из The JavaTM Virtual Machine Specification. И код в BCEL генерить неудобно, особенно переходы вперёд по коду.
Кстати, никто не знает, почему более поздние версии байткода не задокументированы публично? Ведь это должно быть частью спецификации, а она, по идее, открыта.
Что значит «мультиязычен»? Чтобы быть специалистом, например, по Java, нужно обладать тонной опыта, получаемой за немалое время. Я даже с C# на Java в своё время переполз полноценно где-то за полгода. И сейчас считаю себя Java-специалистом, и на вакансию «разработчик .NET» не пойду, ибо теперь годен только в джуниоры. Да, небольшой костыльчик на C# я напишу (как раньше, будучи дотнетчиком, мог на Java). И на Python, и на Ruby, а тем более на PHP я тоже что-то небольшое напишу. Но вот поддерживать крупный проект я бы не взялся. Потому что боюсь что в этом случае нагородил бы тонны говнокода. И, кстати, мне приходилось в жизни довольно много писать на PHP и не сказать, чтобы мне это сильно нравилось. Именно, что «приходилось».
Прост? А как насчёт массивов-хешей? А может, его правила неявного преобразования типа просты и очевидно? Или поведение ссылок? Или банальный приоритет тернарного условного оператора? Или синтаксис интерполяции строк? Ну это только навскидку вспомнилось.
Другие процессы, видя «блокировку» на объекте, либо отдадут его старое значение
Вот! Только проблема в том, что memcache не гарантирует надёжного хранения. Т.е. если ему вдруг понадобилось почистить память, он возьмёт и грохнет какие-то, одному ему ведомо какие, значения. В том числе и «старое» значение может внезапно пропасть. Так что если рассматривать все возможные ситуации, получится нагромождение кодокостылей. И это вместо банального synchronized (monitor) {… } (ну или lock (monitor) {… }, кому как).
либо «подвиснут»
Это каким же макаром? В PHP нет же критических секций.
либо ответят клиенту «обратись через 5 секунд»
Ну что же, запасаемся попкорном и ждём гневной реакции от юзеров.
В общем, memcache — это странный инструмент. PHP же хорош, когда надо быстро сделать сайт с посещением в 3,5 анонимуса. Если планируется, что нагрузка будет на порядки больше, то следует правильно выбирать инструмент. Но кто-то изначально неправильно выбирает инструмент, а потом городит костыли вроде memcache.
Полностью поддерживаю! А ещё меня огорчают программисты, который не различают контекстно-зависимой и контекстно-свободной грамматик, которые удивлённо мигают, видя запись O(n^3) или не понимают, что типизация бывает статической и динамической а так же строгой и нестрогой.
Да порой самым неочевидным образом. Порой просто легче принять верное решение, обладая опытом в разных областях. А если, скажем, приложение становится популярным и им начинают пользоваться миллионы пользователей, то остро встаёт вопрос производительности. А тут уже все методы хороши (в том числе и оптимизация на уровне железа). И не надо говорить про дешевизну железа. Железо — это не что-то, что поставили и работает, его тоже надо обслуживать.
Пожимаю плечами. Может, надо просто ироничнее относиться к себе. Я вот тоже пишу на Java и PHP. И что с того?
Ну всегда полезно взглянуть на себя с другой стороны. Поставить под сомнение свою квалификацию.
А вот это уж точно никак не показывает чью-либо квалификацию.
Помимо просто знания Java или PHP, программисту не мешает хотя бы приблизительно ознакомиться с тем, как работает железо, почитать Кнута, SICP, порешать олимпиадные задачи, написать драйвер и т.д.
Потому SWT…
Ага, этому и посвящена достаточна большая часть Вашей статьи. Вот только чтобы такие вещи утверждать, мало их написать на заборе. И ниже Вы начинаете пояснять, почему так. Так вот моё утверждение: все эти аргументы несостоятельны. Потому что банально неверны. Почему неверны, можно понять, разобравшись путём с XML. В принципе, я в первом комментарии кратко объяснил, что к чему. Но Вы-то ярый борец с «XML-сектой», потому, видимо, разбираться с XML — ниже Вашего достоинства.
Ну какой-то мифический получается веб. В вебе что используется? HTML/XHTML. Формально их синтаксис описать надо? Надо. А это и делается с помощью DTD или более мощного средства, существующего в XML-мире — XML-схем. Ну вот я привёл кусок такого формального описания. Можно было бы и кусок DTD скопипастить. Или вообще кусок текста из стандарта. Однако, текст небезгрешен, его можно трактовать по-всякому, не в пример формальному описанию.
PHP — не лучший шаблонизатор. Я бы предпочёл apache velicity, razor или самописный. Некоторые суровые парни высказались бы в пользу XSLT. Но это неважно. А важно то, что при прямом использовании проставлять кавычки и закрывающие теги в PHP не сильно страшно, вопреки Вашему ещё одному аргументу против XML-синтаксиса HTML (или XHTML, что верно для HTML 4).
Почему XML-синтаксис не прижился? Потому т.н. «веб-программисты» не осилили. Потому что W3C занимались синтаксисом, а не пытались сделать что-то для улучшения семантики HTML. Кстати, HTML5 ничего не говорит о синтаксисе. Точнее, там он присутствует, но описание HTML-элементов даётся в нейтральной манере, чтобы можно было семантику завернуть в любой синтаксис. Кстати, если глянуть на XHTML 1.0, то можно увидеть, что по сути это такой же XML-синтаксис для HTML 4. Так что противопоставлять XHML и HTML5 попросту неверно, т.к. это всё равно, что противопоставлять HTML 4 и HTML5 — разумеется, второй лучше. А почему XHTML 2 так и не был готов? А не потому, что разработчики принадлежали к сектам семантистов и XML-истов, а потому, что были банальными бюрократами.
хотя если почитать XHTML In XML Schema, то увидим такое
<xs:element name="tr"> <xs:complexType> <xs:choice maxOccurs="unbounded"> <xs:element ref="th"/> <xs:element ref="td"/> </xs:choice> <xs:attributeGroup ref="attrs"/> <xs:attributeGroup ref="cellhalign"/> <xs:attributeGroup ref="cellvalign"/> </xs:complexType> </xs:element>и где тут mixed=«true» у complexType?
Или вот никак не могу согласиться:
программы этот контент нам презентуют во вменяемом виде. Конечно, кто-то до сих пор пишет HTML в блокнотике. Но вообще, обычно берут CMS, у которой есть либо WYSIWYG-редактор, либо язык вики-разметки. Так вот в любом случае, текст, введённый пользователем, нужно тщательно отпарсить во внутреннее представления и потом по внутреннему представлению генерить (X)HTML, подставляя, где нужно, теги (в том числе и закрывающие) и экранируя текст. Если всего этого CMS делать не умеет, то грош ей цена
Ну во-первых, не надо уж использовать упомянутый чуть выше PHP (впрочем, лучше вообще его не использовать) не по назначению. Может, не следует генерить (X)HTML из кода, а взять шаблонизатор? Тогда таких проблем не возникнет.
На сколько я знаю, в SAP есть какие-то штуки, написанные на Java. А в общем случае так нельзя сказать. Я вообще на вопрос, на чём написан SAP, получил ответ «на ABAP». Наверное, это недалеко от истины. И, кстати, вроде бы есть какой-то форк MySQL специально для SAP и он даже официально поддерживается.
Кстати, никто не знает, почему более поздние версии байткода не задокументированы публично? Ведь это должно быть частью спецификации, а она, по идее, открыта.
Вот! Только проблема в том, что memcache не гарантирует надёжного хранения. Т.е. если ему вдруг понадобилось почистить память, он возьмёт и грохнет какие-то, одному ему ведомо какие, значения. В том числе и «старое» значение может внезапно пропасть. Так что если рассматривать все возможные ситуации, получится нагромождение кодокостылей. И это вместо банального synchronized (monitor) {… } (ну или lock (monitor) {… }, кому как).
Это каким же макаром? В PHP нет же критических секций.
Ну что же, запасаемся попкорном и ждём гневной реакции от юзеров.
В общем, memcache — это странный инструмент. PHP же хорош, когда надо быстро сделать сайт с посещением в 3,5 анонимуса. Если планируется, что нагрузка будет на порядки больше, то следует правильно выбирать инструмент. Но кто-то изначально неправильно выбирает инструмент, а потом городит костыли вроде memcache.