С Yii работал всего на 1 проекте — не понравился. А именно: стиль кода, логика, документация. Не понимаю, что в нем нашли. Ок, 2-3 года назад выбор был бы понятен, а сейчас — нет.
Интересно:
— Какие плюшки вы в нем нашли?
— Чем он лучше по сравнению с той же Симфони?
Спасибо за статью, 3 часть комикса особенно улыбнула.
Буквально пол года назад стал использовать софтину для хранения паролей. Дико удобно и совсем не напрягает «а какой пароль на этом ресурсе я использовал». С такой штукой можно легко использовать генераторы паролей (использую свой, поэтому о 3 стороне не парюсь).
З.Ы. есть ли смысл выкладывать генератор паролей с открытым кодом? Может уже есть хорошие?
Что-то знакомое для меня. Нас раньше учили, что любой человек открывший ваш код должен понять, что приблизительно он делает, даже если открывший в программировании 0. До сих пор стараюсь писать именно так.
А как вы перешли от потенциальных юзеров данного софта, к его разработчикам? Не могу проследить цепочку.
Вопрос заинтересовал. Зашел на страничку TortoiseHg и прочел описание, но упоминания о том, что этот софт для программистов я не нашел. В прочем, на Википедии (ру) — об этом тоже не написано.
Почему мы считаем, что работа с командной строкой неэффективна?
Дальше этих подпунктов читать не стал. Коротко о ваших аксиомах:
Трата времени на ввод данных. — Юзеру не связанному с программированием — да Трата времени на обучение. — Юзеру не связанному с программированием — да Вероятность ошибки. — Ровно наоборот, действие интерфейса непредсказуемое. Попробуйте сделать git rebase или merge веток с многочисленными конфликтами Нарушение принципов автоматизации. — Автоматизация — явно не кликанье мышкой. Скорее написание скриптов и алиасов
Не работает под IE? Почему бы в этом случае не определить свой console обьект? If ( typeof ( console ) == 'undefined' ) { var console = { ... } }
Насчёт наименований, вынужден с вами не согласиться. Сокращения, тем более короткие и не принятые глобально — это не понятно никому, кроме вас. Если вы всегда разрабатываете один, редактируете свой же код тоже сами — то это конечно ваше личное дело. Но как только другой разработчик начинает читать ваш код — он будет в ступоре.
Представьте, вас попросили, как знакомого программиста, убрать с сайта ошибку в консоли «ReferenceError: ec is not defined». Вы открываете код, нужную строчку и видите:
gc: function( str ) {
var v = this.dgc();
var st = v.indexOf( " " + str + "=" );
if ( st == -1 ) {
st = v.indexOf( str + "=" );
}
if ( st == -1 ) {
v = null;
} else {
st = v.indexOf( "=", st ) + 1;
var e = v.indexOf( ";", st );
if ( ec == -1 ) {
ec = v.length;
}
v = unescape( v.substring( st, e ) );
}
return v;
},
О чём код? Ошибку нашли? Что он делает? Где его проверить?
Тут скорее «на что» рассчитан модернайзер. По-моему так он рассчитан на своеобразные проекты, где JS преобладает над интерфейсом, без бекенд основы (либо с минимальным её использованием).
К примеру:
сайты-визитки, с разными плюшками
внешние плагины, api (ну к примеру те же гугл карты или видео плееры)
смартфонные приложения ещё можно включить в список
Если всё таки «на кого», то я так предполагаю, что на верстальщиков и скрипто-кодеров.
Если идти от размера проекта:
— крохотный — ваш загрузчик бесполезная штука. Легче подключить вручную 0-2 скрипта
— средний — ваш загрузчик бесполезная штука (чуть менее бесполезней чем в прошлом пункте). Если на странице до 5 скриптов, зачем догружать ещё один?
— всё что больше среднего — для таких проектов в основном используют бекенд фреймворки. Которые уже давно научились работать с CSS и с JS (ассеты). Тут ваш загрузчик вообще бесполезен.
В частных случаях может быть иначе. Но опираться на них не стоит.
часто выгоднее иметь весь js код инлайном внутри страницы
Это чем-то обоснованно?
главная страница google где почти 80% кода страницы именно inline js
Ну, если вы заговорили про гугл… Гугл генерирует оутпут, но никак не хардкодит JS прям в шаблоне :) (это только мои догадки кончено, но код вида «google.promos.toast.cl=function(){try{window.gbar.up.sl(g,e,a.k,void 0,1)}catch(b){google.ml(b,!1,{cause:e+»_CL"})}" я бы не назвал редактируемым).
Есди вы назваете блокировкой интерфейса — время, после загрузки DOM, до полной инициализации ui, то это вы зря. Человеку необходимо минимум 0.4 секунды на реакцию, а так же в добавок время до какого либо действия. Скрипты выполняются быстрее, гораздо быстрее.
Для синхронизации базы данных при разработке хорошо использовать фикстуры.
1. Вы никогда не потеряете данные
2. Вы всегда можете их обновить
3. Они контролятся тем же гитом
4. Можно делать разные фикстуры под свои нужды (к примеру тестовая база только для юнит тестов)
Особенно IE7 и IE8, которые до сих пор востребованы. Лично мне не хочется терять от 3% пользователей. А в случаях, когда заказчик к примеру банк, так и потерей всего проекта.
Улыбнул метод удаления продукта из заказа.
А так, спасибо за статью. Пригодится!
С Yii работал всего на 1 проекте — не понравился. А именно: стиль кода, логика, документация. Не понимаю, что в нем нашли. Ок, 2-3 года назад выбор был бы понятен, а сейчас — нет.
Интересно:
— Какие плюшки вы в нем нашли?
— Чем он лучше по сравнению с той же Симфони?
Буквально пол года назад стал использовать софтину для хранения паролей. Дико удобно и совсем не напрягает «а какой пароль на этом ресурсе я использовал». С такой штукой можно легко использовать генераторы паролей (использую свой, поэтому о 3 стороне не парюсь).
З.Ы. есть ли смысл выкладывать генератор паролей с открытым кодом? Может уже есть хорошие?
Вопрос заинтересовал. Зашел на страничку TortoiseHg и прочел описание, но упоминания о том, что этот софт для программистов я не нашел. В прочем, на Википедии (ру) — об этом тоже не написано.
Дальше этих подпунктов читать не стал. Коротко о ваших аксиомах:
Трата времени на ввод данных. — Юзеру не связанному с программированием — да
Трата времени на обучение. — Юзеру не связанному с программированием — да
Вероятность ошибки. — Ровно наоборот, действие интерфейса непредсказуемое. Попробуйте сделать git rebase или merge веток с многочисленными конфликтами
Нарушение принципов автоматизации. — Автоматизация — явно не кликанье мышкой. Скорее написание скриптов и алиасов
Вот какие-то такие мои карандаши.
З.Ы. ссылочка на реализацию утянула на 30 минут рассматривания синтаксисов :)
If ( typeof ( console ) == 'undefined' ) { var console = { ... } }Насчёт наименований, вынужден с вами не согласиться. Сокращения, тем более короткие и не принятые глобально — это не понятно никому, кроме вас. Если вы всегда разрабатываете один, редактируете свой же код тоже сами — то это конечно ваше личное дело. Но как только другой разработчик начинает читать ваш код — он будет в ступоре.
Представьте, вас попросили, как знакомого программиста, убрать с сайта ошибку в консоли «ReferenceError: ec is not defined». Вы открываете код, нужную строчку и видите:
gc: function( str ) { var v = this.dgc(); var st = v.indexOf( " " + str + "=" ); if ( st == -1 ) { st = v.indexOf( str + "=" ); } if ( st == -1 ) { v = null; } else { st = v.indexOf( "=", st ) + 1; var e = v.indexOf( ";", st ); if ( ec == -1 ) { ec = v.length; } v = unescape( v.substring( st, e ) ); } return v; },О чём код? Ошибку нашли? Что он делает? Где его проверить?
К примеру:
сайты-визитки, с разными плюшками
внешние плагины, api (ну к примеру те же гугл карты или видео плееры)
смартфонные приложения ещё можно включить в список
Если всё таки «на кого», то я так предполагаю, что на верстальщиков и скрипто-кодеров.
Но решать вам конечно, для кого написана статья.
Если идти от размера проекта:
— крохотный — ваш загрузчик бесполезная штука. Легче подключить вручную 0-2 скрипта
— средний — ваш загрузчик бесполезная штука (чуть менее бесполезней чем в прошлом пункте). Если на странице до 5 скриптов, зачем догружать ещё один?
— всё что больше среднего — для таких проектов в основном используют бекенд фреймворки. Которые уже давно научились работать с CSS и с JS (ассеты). Тут ваш загрузчик вообще бесполезен.
В частных случаях может быть иначе. Но опираться на них не стоит.
Я так предпочитаю упустить эту микро оптимизацию, вместо которой сделать код понятным, читабельным и редактируемым.
Это чем-то обоснованно?
Ну, если вы заговорили про гугл… Гугл генерирует оутпут, но никак не хардкодит JS прям в шаблоне :) (это только мои догадки кончено, но код вида «google.promos.toast.cl=function(){try{window.gbar.up.sl(g,e,a.k,void 0,1)}catch(b){google.ml(b,!1,{cause:e+»_CL"})}" я бы не назвал редактируемым).
1. Вы никогда не потеряете данные
2. Вы всегда можете их обновить
3. Они контролятся тем же гитом
4. Можно делать разные фикстуры под свои нужды (к примеру тестовая база только для юнит тестов)