В целом идея хорошая, но оригинальность только в том, что работает на стандартных браузерах смартфонов. (И как другие подобные сервисы до этого не додумались).
Плохо то, что это уже 4й подобный стартап, который я вижу за 2010й год. Ничего крайне оригинального.
Может быть я не многие вин-программисты (потому видимо и оказался под *nix), но даже в старые добрые времена, пописывая на php под WinXP использовал cvs и svn ТОЛЬКО из cmd.exe, ибо черепаха мне показалась куда менее понятной чем cvs commit и cvs status и cvs update (а других комманд я тогда еще не знал)
>Но зачем их каждый раз-то принудительно делать?
Так проще потом отслеживать фиксы и фичи.
Еще вам кажется это странным, потому что в svn время на это действие зависит от размера репоза, т.к. надо переключиться. В Mercurial это ни отчего не зависит и переключаться почти не надо. нужно обновиться до stable и пометить рабочую копию названием новой ветки. Тут это гораздо проще.
Я тоже не понимал как и зачем, пока сам не попробовал. Сначала использовал hg как и svn раньше, но как только понял, что ветка в hg это не ветка в svn… Каааааак начал ветвить на каждый чих. Мне проще работать с ветками, тем более никогда не знаешь, когда придется отложить работу над веткой — завтра, или через 5 минут.
>Что конкретно имеется ввиду под «отслеживанием»?
Ничего такого. У меня это проще чем у вас. Есть задача сделать доставки. назвываем ветку delivery и поехали… потом мержим в stable. Через месяц надо сделать что-то еще по доставкам. Обновляемся на delivery. Мержим последние изменения из stable и снова работаем по доставкам. В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
>Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
Я тоже так раньше думал. Надо пробовать. Просто начните какой-нибудь проектик под DVCS и поиграйтесь с ветками.
Головной боли по интегрированию нет. Все сливается очень просто. Если вы в svn ответвили от ветки ответвленной когда-то от ветки (каламбур но специально), а теперь пытаетесь промержить все это в trunk — будет толпа конфликтов, при чем там, где их не должно быть, код то менялся последовательно. В DVCS все это сольется во едино без конфликтов.
Итог: разглагольствовать можно сутками. ПРОБУЙТЕ!!!
Ну помоему IDE здесь совсем не причем.
С eclipse и netbeans mercurial нормально интегрируется, однако мне кажется, что из коммандной строки работать гораздо быстрее и удобнее. Единственное для чего нужен GUI — это мержи и диффы, но тут не обязательно использовать IDE — можно в любом GUI клиенте это делать.
Если такое положение вещей устраивает, то svn Вам вполне подходит.
У нас на каждую фичу отдельная ветка, которая потом сливается в ветку stable.
Таким образом можно легко отслеживать добавленные фичи, можно работать над несколькими фичами и фиксами одновременно, причем все они в разных ветках, а значит изолированны друг от друга.
Проблемы в инструменте контроля версий все-таки есть. Они составляют небольшой процент от всех остальных проблем, НО мне кажется от этих проблем можно избавиться сменив систему контроля версий на распределенную.
Вам бы очень помогло использование DVCS (Mercurial,Git). Чем раньше перейдете на распределенные тем лучше. С SVN легче всего перейти на Mercurial. Тем более если разработка на Windows — с Mercurial будет меньше мучений.
Про логирование можно еще полторы статьи написать.
Хотелось бы сказать, что иногда STDERR и STDOUT слишком мало, ибо нужно сортировать сообщения по теме, а потом отдельно эти темы просматривать.
Я, конечно знаю, что существует grep|sed|awk и т.п., и даже люблю эти утилиты, однако считаю, что иногда удобно просто взять и распечатать файл через tail -n XX или tail -f. Вот тогда на помощь приходит логирование каждой отдельной темы в свой файл.
Приведу пример:
1. обновление данных
2. обновление кода
3. обновление графики .{jpg,gif,png}
4. экспорт данных
5. обработка данных ( тут можно еще побить на отдельные темы )
6. диагностика поддержания работоспособности П.О. (и тут можно на каждый аспект отдельный файл)
При логировании очень полезен шаблон проектирования «Наблюдатель».
1. Тот за кем нужно наблюдать может рассылать сообщения в никуда, если за ним никто не наблюдает.
2. Один наблюдатель может подглядывать за несколькими темами сообщений (объектами, аспектами, добавить свое)
3. За одной темой может следить несколько наблюдателей, каждый из которых может по разному на сообщения реагировать (писать в файл, слать в Jabber и т.д.)
В этом плане рекомендую посмотреть на Logger в стандартной библиотеке Python — ИМХО мега юзабельно!
Преимущество я могу назвать преред Symfony 1.4.
Limb3 — намного более гибок и удобен.
Интерфейсы в лимбе (программные интерфейсы) просто вылизаны до блеска. Компоненты разделены так, что ничего не мешает работы. Гибкость на уровне — в любой момент можно расширить класс или заменить своим для получения нужного функционала.
{{MACRO}} — не шаблонизатор, а СКАЗКА! Есть удобные теги форм интегрирующиеся с контроллерами, есть теги пагинации списков и вывода списков. Есть теги перевода {{i18n }}This text will display in Russian{{/18n}}
Ну и просто отличный расширяемый ActiveRecord, который позволяет родной SQL, в отличии от Doctrine + DQL (знаю, что там тоже можно, но через Ж...)
З.Ы. Кодогенератор — если даже не трушно в чьем-то мире, то уж точно — очень удобно!
Мне не раз нужен был сохраненный контекст лямбды. Например тогда, когда стек замыканий вырастает до 5-6 функций и этого никак нельзя избежать — асинхронность.
Однако не понимаю, чем автору непонравился self! Вот self2 — это уже маразм, и когда требуется self2 есть 2 варианта действий:
Застрелиться либо дать нормальные имена для self и self2, как советует автор
Но вот когда один только self — я считаю — это нормально.
Я на купленный лицензионный фильм смотрю с другими мыслями:
Вот если б скачал — смотрел бы сразу фильм, а не идиотскую антипиратскую рекламу, которая не перематывается! Тьфу!!! Больше не буду покупать!!!
Ага! Неумение печатать в слепую лечится за две недели (из собственного опыта).
И лечится просто — снимите все кнопки и расставьте в хаотичном порядке. Смотреть на клавиатуру станет бесполезно, и глаза устремятся в экран. Две недели мучений, из которых самый сложный — первый день, а потом приходит просветление и счастье :)
Плохо то, что это уже 4й подобный стартап, который я вижу за 2010й год. Ничего крайне оригинального.
Не важно — добавляешь ты или убавляешь кому-то карму — с тебя ровно столько же в минус.
Иначе
>>Повысил другу на десятку — теряешь сам один балл своей кармы
Ну и друг тебе, и ты ему, в итоге бесконечный источник кармы получается.
А за развернутую информацию огромное спасибо.
Так проще потом отслеживать фиксы и фичи.
Еще вам кажется это странным, потому что в svn время на это действие зависит от размера репоза, т.к. надо переключиться. В Mercurial это ни отчего не зависит и переключаться почти не надо. нужно обновиться до stable и пометить рабочую копию названием новой ветки. Тут это гораздо проще.
Я тоже не понимал как и зачем, пока сам не попробовал. Сначала использовал hg как и svn раньше, но как только понял, что ветка в hg это не ветка в svn… Каааааак начал ветвить на каждый чих. Мне проще работать с ветками, тем более никогда не знаешь, когда придется отложить работу над веткой — завтра, или через 5 минут.
>Что конкретно имеется ввиду под «отслеживанием»?
Ничего такого. У меня это проще чем у вас. Есть задача сделать доставки. назвываем ветку delivery и поехали… потом мержим в stable. Через месяц надо сделать что-то еще по доставкам. Обновляемся на delivery. Мержим последние изменения из stable и снова работаем по доставкам. В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
>Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
Я тоже так раньше думал. Надо пробовать. Просто начните какой-нибудь проектик под DVCS и поиграйтесь с ветками.
Головной боли по интегрированию нет. Все сливается очень просто. Если вы в svn ответвили от ветки ответвленной когда-то от ветки (каламбур но специально), а теперь пытаетесь промержить все это в trunk — будет толпа конфликтов, при чем там, где их не должно быть, код то менялся последовательно. В DVCS все это сольется во едино без конфликтов.
Итог: разглагольствовать можно сутками. ПРОБУЙТЕ!!!
С eclipse и netbeans mercurial нормально интегрируется, однако мне кажется, что из коммандной строки работать гораздо быстрее и удобнее. Единственное для чего нужен GUI — это мержи и диффы, но тут не обязательно использовать IDE — можно в любом GUI клиенте это делать.
У нас на каждую фичу отдельная ветка, которая потом сливается в ветку stable.
Таким образом можно легко отслеживать добавленные фичи, можно работать над несколькими фичами и фиксами одновременно, причем все они в разных ветках, а значит изолированны друг от друга.
Я последний год работаю с Memorial и очень доволен. Обратно на svn не тянет.
Главным преимуществом считаю легкое ветвление и слияние веток.
Очень рекомендую!
Хотелось бы сказать, что иногда STDERR и STDOUT слишком мало, ибо нужно сортировать сообщения по теме, а потом отдельно эти темы просматривать.
Я, конечно знаю, что существует grep|sed|awk и т.п., и даже люблю эти утилиты, однако считаю, что иногда удобно просто взять и распечатать файл через tail -n XX или tail -f. Вот тогда на помощь приходит логирование каждой отдельной темы в свой файл.
Приведу пример:
1. обновление данных
2. обновление кода
3. обновление графики .{jpg,gif,png}
4. экспорт данных
5. обработка данных ( тут можно еще побить на отдельные темы )
6. диагностика поддержания работоспособности П.О. (и тут можно на каждый аспект отдельный файл)
При логировании очень полезен шаблон проектирования «Наблюдатель».
1. Тот за кем нужно наблюдать может рассылать сообщения в никуда, если за ним никто не наблюдает.
2. Один наблюдатель может подглядывать за несколькими темами сообщений (объектами, аспектами, добавить свое)
3. За одной темой может следить несколько наблюдателей, каждый из которых может по разному на сообщения реагировать (писать в файл, слать в Jabber и т.д.)
В этом плане рекомендую посмотреть на Logger в стандартной библиотеке Python — ИМХО мега юзабельно!
И думаю что производительность будет не хуже, чем у популярных фреймворков.
Limb3 — намного более гибок и удобен.
Интерфейсы в лимбе (программные интерфейсы) просто вылизаны до блеска. Компоненты разделены так, что ничего не мешает работы. Гибкость на уровне — в любой момент можно расширить класс или заменить своим для получения нужного функционала.
{{MACRO}} — не шаблонизатор, а СКАЗКА! Есть удобные теги форм интегрирующиеся с контроллерами, есть теги пагинации списков и вывода списков. Есть теги перевода {{i18n }}This text will display in Russian{{/18n}}
Ну и просто отличный расширяемый ActiveRecord, который позволяет родной SQL, в отличии от Doctrine + DQL (знаю, что там тоже можно, но через Ж...)
З.Ы. Кодогенератор — если даже не трушно в чьем-то мире, то уж точно — очень удобно!
Однако не понимаю, чем автору непонравился self! Вот self2 — это уже маразм, и когда требуется self2 есть 2 варианта действий:
Застрелиться либо дать нормальные имена для self и self2, как советует автор
Но вот когда один только self — я считаю — это нормально.
Вот если б скачал — смотрел бы сразу фильм, а не идиотскую антипиратскую рекламу, которая не перематывается! Тьфу!!! Больше не буду покупать!!!
И лечится просто — снимите все кнопки и расставьте в хаотичном порядке. Смотреть на клавиатуру станет бесполезно, и глаза устремятся в экран. Две недели мучений, из которых самый сложный — первый день, а потом приходит просветление и счастье :)