Я думал такое сделать (если добавить новый Tab в Add Reference… в VS, будет совсем удобно, а это вполне возможно). Но тут важен сам сайт (репозиторий компонентов, etc). Это сделать интересно, но долго.
(мелочь: название не очень: octalforty Componento, скорее с Java ассоциируется).
Firefox, IE7 and Opera 9 all could render the custom tags style correctly in the document served as text/html.
…
IE7 has a one important characteristic — it does not render custom tag styles unless…
Понятно что в случае с аттрибутами стилизация не важна.
XHTML5 существует как XML описание HTML5.
То есть:
<body ex:item="bug" xmlns:ex="http://example.net">
<h1>Issue <span ex:prop="number">12941</span>:
<span ex:prop="title">Too many pies in the pie factory</span></h1>
является валидным XHTML5.
То есть непонятно зачем нужен itemprop, если есть xml namespaces.
Возвращаясь к статье: я счас заканчиваю работать в проекте, который изначально имеет БЛ в ДБ (Oracle). Руководитель этого проекта поднялся на нем за тройку лет с никого до заместителя вице-президента
Да, потому что проект может быть написан плохо, но всё равно решать все поставленные задачи, или если эстимейты неважны, или всё строго и нельзя заменить поставщика, и во многих других случаях. Может быть он прекрасный руководитель, но плохой архитектор, whatever.
С другой стороны, например, строители у нас строят плохо, а получают сверхприбыли — это тоже пример для подражания?
Здравомыслящий клиент не станет обращаться к тем, кто вместо реализации его идеи — начинает складывать о ней свое мнение
В самом деле? На самом деле хорошие клиенты, которых я видел, были очень заинтересованы в нашем мнении. Если команда способна понять не только техническую, а бизнес задачу и предложить лучшее решение, это очень ценится разумными клиентами. Конечно, за клиентом всегда последнее слово, и два раза одно и то же не предлагают, поэтому он и не боится слушать.
А идея мне неприятна я говорил об идее писать плохо ради собственной выгоды, которая и клиенту неприятна обычно (если это аутсурсинг, по крайней мере) — они всё-таки хотят верить что технические задачи будут решаться честно.
Топы в разных компаниях разные, но вообще-то все компании-заказчики, которые я до сих пор видел, были довольно экономны (и чем больше компания, тем более мелочной она часто оказывается).
Я (да в общем и компания где я работаю) никогда не работал с целью создать рабочие места таким образом, и сама идея мне неприятна.
С другой стороны, кто сказал что клиент с таким приложением пойдёт к той же компании, которая его исходно написала? Чаще будет так, что он выслушает estimate и отправится к другим, раз уж всё равно надо переписывать. К индусам или китайцам, например, раз качество всё равно не отличается.
С «навороченной» архитектурой — нет, с хорошей архитектурой — да.
Дело не в том чтобы сделать «архитектуру», дело в том чтобы дополнения более-менее придерживались принципа open-closed — то есть можно было бы добавлять новые штуки, почти не меняя старые.
У меня тоже есть опыт работы в проектах для больших компаний. Я видел средние проекты, плохие проекты, и хорошие проекты.
Так вот плохие проекты могут застрять ни на чём на долгое время, а хорошие проекты двигаются вперёд равномерно и довольно неплохо.
Такой вопрос говорит о том, насколько человек заинтересован в технологии, которую использует.
Если вы знаете, как работают события, вы знаете и ответ на этот вопрос, это несложно.
Зато он проверяет одновременно понимание событий и способность сообразить ответ на новый, неизвестный ранее вопрос.
У меня очень хорошая команда, в том числе потому что любой из них не стал бы кричать про такую задачу «а зачем это вообще надо?!», а ответил бы, или хотя бы задумался. Потому что приятно работать с людьми, которым интересно, а не просто хочется получить очередную зарплату.
Конечно, нельзя по такому вопросу решать исход собеседования или оклад, но бесполезным я бы его тоже не назвал.
Конечно исходное приложение быстрее слепить как попало, если оно не сложное.
А вот добавлять новые возможности вы будете быстрее и без того, чтобы всё сломалось.
Спасибо, хотя так спорить не интересно, если оба человека слишком вменяемые. :)
Мне на самом деле нравятся все фреймворки (4-ый C# разочаровывает, это да), потому что хотя в WPF куча недостатков со стилями, это всё очень клёвая штука, а Linq спасает от кучи циклов и прочих мучений на пустом месте. На самом деле с выходом Linq C# стал удобнее и иногда короче, чем Perl, что я считаю большим достижением.
Для Javascript в Visual Studio есть отличный дебаггер (хотя, конечно, к Андроиду он не мог бы подсоединиться), и Firebug тоже ничего. Я бы не сказал чтто его так уж мучительно отлаживать. Плюс там прекрасное метапрограммирование.
Ладно, для одного Where for убедителен, но мне не кажется что в Java будет только чуть-чуть длиннее (без yield).
А сортировка .OrderBy(x => x.LastName).ThenBy(x => x.FirstName).ThenByDescending(x => x.Salary), например, уже так просто не получится — придётся ре-имплементировать весь алгоритм сортировки.
С джавой у меня, кажется, та же проблема что и у автора — ничего такой язык, понятно за что его любит enterprise, но он же скучный by design. Это было и в одной презентации про closures: Java не язык для экспериментов. Из-за этого приходится намного длиннее писать во многих случаях.
Если есть выбор, C# или, кстати, Javascript интереснее (хотя JavaGI рулит как концепт, если бы все архитекторы Java мыслили так же широко, было бы отлично).
Смущает что Google, который в остольном довольно инновационен, продвигает этот язык.
Я думал такое сделать (если добавить новый Tab в Add Reference… в VS, будет совсем удобно, а это вполне возможно). Но тут важен сам сайт (репозиторий компонентов, etc). Это сделать интересно, но долго.
(мелочь: название не очень: octalforty Componento, скорее с Java ассоциируется).
Понятно что в случае с аттрибутами стилизация не важна.
И это касается тегов, аттрибуты с неймспейсом работают в любых браузерах и сейчас.
Я использовал bind:href=«expression» для небольшого databinding-движка, например.
Вовсе нет, по моему лучше так, как я написал. Мысли про спецификацию правильные, но не относятся к моему примеру.
по сути дела SVG и MathML в HTML5 — это hardcoded hack, который обходит невозможность полного синтаксиса XML.
То есть:
<body ex:item="bug" xmlns:ex="http://example.net">
<h1>Issue <span ex:prop="number">12941</span>:
<span ex:prop="title">Too many pies in the pie factory</span></h1>
является валидным XHTML5.
То есть непонятно зачем нужен itemprop, если есть xml namespaces.
Да, потому что проект может быть написан плохо, но всё равно решать все поставленные задачи, или если эстимейты неважны, или всё строго и нельзя заменить поставщика, и во многих других случаях. Может быть он прекрасный руководитель, но плохой архитектор, whatever.
С другой стороны, например, строители у нас строят плохо, а получают сверхприбыли — это тоже пример для подражания?
В самом деле? На самом деле хорошие клиенты, которых я видел, были очень заинтересованы в нашем мнении. Если команда способна понять не только техническую, а бизнес задачу и предложить лучшее решение, это очень ценится разумными клиентами. Конечно, за клиентом всегда последнее слово, и два раза одно и то же не предлагают, поэтому он и не боится слушать.
А идея мне неприятна я говорил об идее писать плохо ради собственной выгоды, которая и клиенту неприятна обычно (если это аутсурсинг, по крайней мере) — они всё-таки хотят верить что технические задачи будут решаться честно.
Топы в разных компаниях разные, но вообще-то все компании-заказчики, которые я до сих пор видел, были довольно экономны (и чем больше компания, тем более мелочной она часто оказывается).
С другой стороны, кто сказал что клиент с таким приложением пойдёт к той же компании, которая его исходно написала? Чаще будет так, что он выслушает estimate и отправится к другим, раз уж всё равно надо переписывать. К индусам или китайцам, например, раз качество всё равно не отличается.
Дело не в том чтобы сделать «архитектуру», дело в том чтобы дополнения более-менее придерживались принципа open-closed — то есть можно было бы добавлять новые штуки, почти не меняя старые.
У меня тоже есть опыт работы в проектах для больших компаний. Я видел средние проекты, плохие проекты, и хорошие проекты.
Так вот плохие проекты могут застрять ни на чём на долгое время, а хорошие проекты двигаются вперёд равномерно и довольно неплохо.
Если вы знаете, как работают события, вы знаете и ответ на этот вопрос, это несложно.
Зато он проверяет одновременно понимание событий и способность сообразить ответ на новый, неизвестный ранее вопрос.
У меня очень хорошая команда, в том числе потому что любой из них не стал бы кричать про такую задачу «а зачем это вообще надо?!», а ответил бы, или хотя бы задумался. Потому что приятно работать с людьми, которым интересно, а не просто хочется получить очередную зарплату.
Конечно, нельзя по такому вопросу решать исход собеседования или оклад, но бесполезным я бы его тоже не назвал.
А если нужна одна и та же логика для многих сущностей?
Вообще процедурное программирование живёт до какого-то уровня сложности, но я бы не сказал что оно проще, особенно на ограниченном языке типа SQL.
А вот добавлять новые возможности вы будете быстрее и без того, чтобы всё сломалось.
Мне на самом деле нравятся все фреймворки (4-ый C# разочаровывает, это да), потому что хотя в WPF куча недостатков со стилями, это всё очень клёвая штука, а Linq спасает от кучи циклов и прочих мучений на пустом месте. На самом деле с выходом Linq C# стал удобнее и иногда короче, чем Perl, что я считаю большим достижением.
Для Javascript в Visual Studio есть отличный дебаггер (хотя, конечно, к Андроиду он не мог бы подсоединиться), и Firebug тоже ничего. Я бы не сказал чтто его так уж мучительно отлаживать. Плюс там прекрасное метапрограммирование.
А сортировка .OrderBy(x => x.LastName).ThenBy(x => x.FirstName).ThenByDescending(x => x.Salary), например, уже так просто не получится — придётся ре-имплементировать весь алгоритм сортировки.
С джавой у меня, кажется, та же проблема что и у автора — ничего такой язык, понятно за что его любит enterprise, но он же скучный by design. Это было и в одной презентации про closures: Java не язык для экспериментов. Из-за этого приходится намного длиннее писать во многих случаях.
Если есть выбор, C# или, кстати, Javascript интереснее (хотя JavaGI рулит как концепт, если бы все архитекторы Java мыслили так же широко, было бы отлично).
Смущает что Google, который в остольном довольно инновационен, продвигает этот язык.