Самое главное преимущество для предпринимателя заключается в том, что все становится более прозрачным во всех отношениях
О да, для этого непременно надо кассы внедрять))
Вот говорят о магазинах и тд. А что делать сайтам, которые позволяют пополнить счет с запасом, и лишь потом тратить с него деньги на различные услуги? Как должен чек выглядеть, какую номенклатуру туда писать?
Соответственно, это только для новых продуктов или при заметной переработке существующих, так? Для багфиксов и мелких улучшений это будет выглядеть бюрократией, имхо
Слегка оффтоп, но все же спрошу. На недавней конференции в Баду рассказывали про техническое ревью, когда разработчик-исполнитель описывает в тикете, как он понял постановку задачи. То есть по сути переводит с менеджерского на разработческий. И далее это ревью проверяется командой на корректность.
Можете немного подробнее рассказать, как это реализовано, всегда ли оно выполняется и тд.
Я даже для своих собственных нужд на автомате создаю Гугл-документ. Просто потому, что высока вероятность появления необходимости его показать или начать совместное редактирование. Excel не открывал уже наверное года два.
Ну и сотрудников в компании потихоньку пересаживаем на ГДокс, очень удобно.
PS. Еще добавлю — системы контроля сотрудников, типа вашей, считаю ущербными. Так как они нужны только ущербным руководителям, не умеющим контролировать результаты, и из-за этого контролирующим активность. Подобные руководители активно выступают против удаленки. Собственно, это тоже в книге есть :)
А собеседование удаленщика ничем не отличается от личного. Все равно неправильность раскрывается только через какое-то время. Можно минимизировать риски, если сразу ставить конкретные задачи и отслеживать результаты его работы СРАЗУ.
Видимо дело в «участвующий в съемке человек сможет подписать простым движением пальца по экрану». То есть не надо будет потом искать человека для подписи документа (или таскать бланки с собой).
У человека с трудом хватает времени на развитие CMS, а Вы ему предлагаете еще и фреймворк тащить на себе.
Другое дело, что надо посмотреть на уже существующие форки (насколько я помню, еще несколько CMS привели к таким ответвлениям) и возможно присоединиться к ним. Другой вариант — познакомиться с текущей командой разработчиков Kohana. Да, фреймворк еще не совсем умер, по крайней мере были шевеления в github.com/kohana/kohana/tree/3.4/develop.
Чем компьютерные программы не угодили? С живыми проще на каком-нить Chess Planet порубиться, но насчет планшета не уверен, в последний раз приходилось через винду играть.
30 секунд — это очень много. В последнее время блиц и суперблиц (это именно так называется, «быстрые» шахматы подразумевают контроль по 15-30 минут) становятся все более популярными, ибо зрелищность у них намного выше, чем у классических многочасовых партий.
Мы (игроки уровня КМС) играли в свое время по минуте, позволяет довольно далеко в партии продвигаться (хотя чаще бывают глупые ошибки из-за спешки). Так что в таком матче я бы поставил на Карлсена, что он выиграет 10 из 10.
Не совсем понял, почему I18n::lang() должен устанавливать язык в зависимости от контроллера. То есть перевод одной и той же кнопки в шапке будет разным для разных страниц (точнее, он будет продублирован в разных файлах)?
Если говорить о роутинге, вероятно лучше было бы создать отдельные классы (Route_I18n, HTML_I18n) для работы с такими адресами, и в них завернуть всю необходимую функциональность. Константа LANG тоже неправославна, хотя бы из-за возможного конфликта с подключенными вендорными библиотеками.
Ну и, конечно, вопрос перевода контента не раскрыт. По сути, все вышеописанное позволяет делать легкий перевод интерфейса. И то, иногда бывает удобнее создать отдельные шаблоны для разных языков, чем дергать постоянно __() для отдельных элементов), тут напрашивается класс View_I18n, который бы проверял наличие шаблона для текущего языка. И тд
Не являюсь поклонником Yii, потому не пинайте :) Какой смысл в методе populate()? Почему контроллер должен каким-то образом заполнять модель? Намного логичнее выглядит $model->populate($_POST).
О да, для этого непременно надо кассы внедрять))
Вот говорят о магазинах и тд. А что делать сайтам, которые позволяют пополнить счет с запасом, и лишь потом тратить с него деньги на различные услуги? Как должен чек выглядеть, какую номенклатуру туда писать?
Можете немного подробнее рассказать, как это реализовано, всегда ли оно выполняется и тд.
Ну и сотрудников в компании потихоньку пересаживаем на ГДокс, очень удобно.
Другое дело, что надо посмотреть на уже существующие форки (насколько я помню, еще несколько CMS привели к таким ответвлениям) и возможно присоединиться к ним. Другой вариант — познакомиться с текущей командой разработчиков Kohana. Да, фреймворк еще не совсем умер, по крайней мере были шевеления в github.com/kohana/kohana/tree/3.4/develop.
Мы (игроки уровня КМС) играли в свое время по минуте, позволяет довольно далеко в партии продвигаться (хотя чаще бывают глупые ошибки из-за спешки). Так что в таком матче я бы поставил на Карлсена, что он выиграет 10 из 10.
Если говорить о роутинге, вероятно лучше было бы создать отдельные классы (Route_I18n, HTML_I18n) для работы с такими адресами, и в них завернуть всю необходимую функциональность. Константа LANG тоже неправославна, хотя бы из-за возможного конфликта с подключенными вендорными библиотеками.
Ну и, конечно, вопрос перевода контента не раскрыт. По сути, все вышеописанное позволяет делать легкий перевод интерфейса. И то, иногда бывает удобнее создать отдельные шаблоны для разных языков, чем дергать постоянно __() для отдельных элементов), тут напрашивается класс View_I18n, который бы проверял наличие шаблона для текущего языка. И тд
В любом случае, абсолютно субъективный получится рейтинг. Надо было хотя бы разбить по категориям.