У меня было всего 3 расширения, одно из готорых Google Docs, двумя другими уже давно пользовалась. А таки в одном из них оказался рекламный вирус (может и не вирус) — Smooth Gestures, ниже уже о нем упоминалось. Хорошо, что их встраиваемый джаваскрипт был кривой и выдавал ошибку в консоли. А так — сидела бы и не знала что происходит.
Так что малое количество расширений еще ничего не гарантирует.
Не вижу связи знания ЗП с прочтением книг.
Зато вполне согласна, что если у компании открытая система начисления ЗП, то проблем никаких нет и можно разглашать информацию. А вот если компания расчитывает на «не просит, так и не будем повышать», то тогда бояться есть чего, конечно :)
Мне, как программисту хочется как раз больше думать о программистском, чем изучать рынок зарплат по моей специальности/должности и зная уровень ЗП в моей компании на моей должности, я вторым не заморачиваюсь.
В статье описан подход, как я поняла, когда менеджер постоянно меняется. Т.е. каждый из членов команды должен быть, как минимум, ответственен.
Я не хочу сказать, что это плохая или нерабочая стратегия. Согласна, что такой подход мотивирует.
Но когда роль менеджера постоянно берет новый человек это может выбивать из колеи всю команду, если менеджер не подойдет к делу серьезно. Да даже если и серьезно, зачастую с непривычки управлять менеджер что-то упускает. Стабильность и продуктивность наступает, когда один и тот же человек управляет проектом уже на следуюзих итерациях.
Такая стратегия хороша для небольшой команды, которая знает цель своего проекта. Как только цель будет расплывчата или понята разными по-разному, проект начнет расшатываться из стороны в сторону, а не расти вверх. Именно об этом я и говорила относительно HR — подобрать правильного сотрудника для конкретного проекта, а не подобрать просто хорошего универсального сотрудника.
20 прочитал, пошел спать, комп выключил. Заново все это листать и вспоминать на чем остановился?
Ну или если инет ужасно тупит. Сидишь крутишь-крутишь, а потом просто все перестало работать т.к. инета нет. Рефрешишь страницу — и опять крутишь до посинения. Не спорю, что это уже могут быть и детали реализации. Но с обычным пейджингом как-то проще и удобнее.
Даришь всем остальным. Гугл дарит инструмент, идею, дает возможности. Сколько можно заработать на таком «хобби» и сколько можно получить от всеобщего результата? Или если не заработать, то как использовать такой труд с большей пользой?
У нас — ревью всего нового кода. Но такого варианта нет :)
Насчет пересмотра старого… нацеленно вроде не пересматриваем, разве что заодно с какими-то фиксами.
Хм. Кстати, QA у нас приходится бывает много чего считать.
А так — редко вообще приходится считать, хотя бывает случается. ЗП например пересчитать — все ли правильно начислили :) Сдачу посчитать в магазине. Часы в сутки пересчитать. Перевести время из одного часового пояса в другой. В общем, на самом деле, считать есть что.
Хелпер Data.php нужен, если предполагается использовать переводы. Если не предполагается ни переводить, ни использовать хелперы, то можно, по-моему, не «заводить» его.
Не совсем понимаю о каком профиле пользователя идет.
В базе хранится дата/время по UTC: 2011-03-13 00:00:00. Сколько это будет для Лос-Анжелеса? Сколько для Киева? Сколько для Москвы?
работаем с UTC, в БД храним в UTC, преобразуем в/из только в момент показа пользователю/получения данных из формы и бед не знаем.
Не всегда так можно. Было дело… надо было выбирать из базы данные разбитые по дням. А дни — не по UTC, конечно же :) Проще таки группировать данные уже при выборке.
Россия не единственная такая страна. Многие пояса какое-то время попереключались между летними/зимними временами, а потом перестали. Все это хранится в спец.базах.
Так что малое количество расширений еще ничего не гарантирует.
Зато вполне согласна, что если у компании открытая система начисления ЗП, то проблем никаких нет и можно разглашать информацию. А вот если компания расчитывает на «не просит, так и не будем повышать», то тогда бояться есть чего, конечно :)
Мне, как программисту хочется как раз больше думать о программистском, чем изучать рынок зарплат по моей специальности/должности и зная уровень ЗП в моей компании на моей должности, я вторым не заморачиваюсь.
Я не хочу сказать, что это плохая или нерабочая стратегия. Согласна, что такой подход мотивирует.
Но когда роль менеджера постоянно берет новый человек это может выбивать из колеи всю команду, если менеджер не подойдет к делу серьезно. Да даже если и серьезно, зачастую с непривычки управлять менеджер что-то упускает. Стабильность и продуктивность наступает, когда один и тот же человек управляет проектом уже на следуюзих итерациях.
Такая стратегия хороша для небольшой команды, которая знает цель своего проекта. Как только цель будет расплывчата или понята разными по-разному, проект начнет расшатываться из стороны в сторону, а не расти вверх. Именно об этом я и говорила относительно HR — подобрать правильного сотрудника для конкретного проекта, а не подобрать просто хорошего универсального сотрудника.
Я только хотела описать варианты, где такая фича неудобна.
Ну или если инет ужасно тупит. Сидишь крутишь-крутишь, а потом просто все перестало работать т.к. инета нет. Рефрешишь страницу — и опять крутишь до посинения. Не спорю, что это уже могут быть и детали реализации. Но с обычным пейджингом как-то проще и удобнее.
Насчет пересмотра старого… нацеленно вроде не пересматриваем, разве что заодно с какими-то фиксами.
А так — редко вообще приходится считать, хотя бывает случается. ЗП например пересчитать — все ли правильно начислили :) Сдачу посчитать в магазине. Часы в сутки пересчитать. Перевести время из одного часового пояса в другой. В общем, на самом деле, считать есть что.
В базе хранится дата/время по UTC: 2011-03-13 00:00:00. Сколько это будет для Лос-Анжелеса? Сколько для Киева? Сколько для Москвы?
Не всегда так можно. Было дело… надо было выбирать из базы данные разбитые по дням. А дни — не по UTC, конечно же :) Проще таки группировать данные уже при выборке.