Comments 100
Еще есть мега прокаченные REPL, как ipython (ipython-notebook) для питона.
еще бы приучить себя к repl вместо excel как калькулятора, было бы вообще круто.
UFO just landed and posted this here
UFO just landed and posted this here
Те кто плюсуют не испытали мощь математических инструментов. Откройте для себя Octave, Maxima, Scilab, R… Или Matlab, да хотя бы и MathCad! Постройте говорящие графики в Origin или Qtiplot… И после этого откройте Excel. Желательно последней версии, в которой интерфейс предельно «упрощён» и до всех действительно продвинутых функций нужно добираться в десятки кликов. Уверяю вас вы его с ужасом закроете через несколько минут.
Эксель хорош не для продвинутых функций, а для выполнения простых функций с не очень хорошо вычищенными данными.
У меня такое часто бывает: открыл таблицу из CSV, а потом оказывается, что после сортировки треть таблицы вообще не нужна, в другой неправильно оформатированные данные, какие-то столбцы лишние, какие-то требуют перенормировки и т.п.
В этом отношении трудно придумать что-то мощнее Excel.
Matlab и иже с ними хорошо работают, когда мы знаем точно, что на входе, и хотим получить что-то конкретное на выходе.
У меня такое часто бывает: открыл таблицу из CSV, а потом оказывается, что после сортировки треть таблицы вообще не нужна, в другой неправильно оформатированные данные, какие-то столбцы лишние, какие-то требуют перенормировки и т.п.
В этом отношении трудно придумать что-то мощнее Excel.
Matlab и иже с ними хорошо работают, когда мы знаем точно, что на входе, и хотим получить что-то конкретное на выходе.
Да ладно? Сколько кликов мышкой нужно, чтобы посчитать такое?
In [1]: from math import sin
In [2]: from itertools import product
In [3]: sum((x * sin(y) ** 2 for x, y in product(xrange(10), repeat=2) if x * y % 3 == 0))
Out[3]: 91.92988708509623
+1 за Java REPL.
С# — встроенные в Visual Studio средства, для mono и linux решения не нашел (но уверен, оно есть).
У Mono профайлер встроен в рантайм. Достаточно с нужными опциями и параметрами окружения запустить. REPL тоже в базовой поставке идёт.
Большое спасибо за REPL и Cling в частности.
Вот еще REPL — repl.it. Из плюсов — онлайн и есть возможность использовать разные языки (python, ruby, javascript, brainfuck, etc).
REPL на стероидах для C# под винду — это LINQPad. Маст хэв.
Darcs — если Вы фанат Haskell — можете попробовать продукт на Вашем любимом языке, в остальном ничего примечательного.
Patch theory, spontaneous branches? Интерактивность?
Система контроля версий (git, svn, hg, bazaar и их друзья) — один из самых важных инструментов, о котором, к моему сожалению очень многие не знают.
За свою жизнь не видел вживую ни одного такого разработчика.
Статья оставляет смешанные впечатления, с одной стороны REPL и профайлер (не rocket science, но обычно используются нечасто), с другой — основы вроде VCS. Это если бы в учебнике математики интегралы шли бы после умножения.
Ну тех, которые совсем ничего не слышали, наверно и правда мало. А вот знающих, но не использующих из-за лени/«нехватки времени» (на изучение), вполне хватает.
Очень много не знающих/не умеющих в смежных с программированием областях, например, в области верстки, хотя верстальщикам тоже не помешало бы иметь представление о VCS.
Не знаю кто эти ребята больше, разработчики или инженеры, но что восемь лет назад, когда я от них ушёл, что сейчас — в одном большом и очень известном НИИ в Питере про cvs и не слышали. Хотя разрабатывают неплохой софт для нужд своей отрасли. Пытаюсь внедрить у них git, когда приходится подрабатывать.
Другое дело, что они и на хабр вряд ли заходят, и шансов самим попасть на эту статью у них не много.
Другое дело, что они и на хабр вряд ли заходят, и шансов самим попасть на эту статью у них не много.
Осмелюсь полюбопытствовать, а чем же вам не нравится svn?
Рекомендую довольно старое выступление Линуса Торвальдса на эту тему. В целом большинство недостатков — следствие централизованности. Нельзя нормально работать без интернета (в самолете, например); очень тяжелые ветки, вы не станете заводить новую под каждый фикс. Приходится работать только с крупными изменениями, тогда как с DVCS можно комитить почти каждое атомарное изменение.
Но лучше, конечно, послушать тех, кто долго использовал svn, а потом перешел на git.
Но лучше, конечно, послушать тех, кто долго использовал svn, а потом перешел на git.
Спасибо, в принципе звучит обоснованно.
Я на работе как раз использую svn (а долгое время там никакого контроля версий не было — да, такое действительно бывает). В принципе, для наших условий (менее 10 человек в команде, минимум совместного редактирования одних и тех же файлов) — его вполне хватает.
Я в курсе, что гит сейчас очень популярен и несколько раз уже подумывал на него переехать, но как-то не складывается. Меня отталкивает в первую очередь необходимость плотно использовать консоль и отличия в логике работы. Зачем, например, постоянно делать ветки под каждый чих, а потом их мерджить? История в svn линейна и читается как-то легче, чем ветвящиеся графики в git (ну, лично мне так кажется).
Вот насчет работы без интернета — это да, правда. Пару раз локалка ложилась ЗА ДЕНЬ до сдачи проекта и svn-сервер был недоступен. Вот это было весьма болезненно, доложу я вам :)
Я на работе как раз использую svn (а долгое время там никакого контроля версий не было — да, такое действительно бывает). В принципе, для наших условий (менее 10 человек в команде, минимум совместного редактирования одних и тех же файлов) — его вполне хватает.
Я в курсе, что гит сейчас очень популярен и несколько раз уже подумывал на него переехать, но как-то не складывается. Меня отталкивает в первую очередь необходимость плотно использовать консоль и отличия в логике работы. Зачем, например, постоянно делать ветки под каждый чих, а потом их мерджить? История в svn линейна и читается как-то легче, чем ветвящиеся графики в git (ну, лично мне так кажется).
Вот насчет работы без интернета — это да, правда. Пару раз локалка ложилась ЗА ДЕНЬ до сдачи проекта и svn-сервер был недоступен. Вот это было весьма болезненно, доложу я вам :)
Я про «ветки на каждый чих» прокомментирую. Это очень полезно, если разные люди работают над разными задачами. У каждого своя локальная ветка (до тех пор, пока фича не становится готовой). В основную ветку вливается уже готовый результат (при желании в виде одного коммита); при этом история остается вполне себе линейной. Ну это один из подходов.
В моей практике были случаи, когда один подход не срабатывал, я пытался реализовать ту же функциональность иначе. Так у меня существовали две параллельные ветки для одной и той же фичи. В случае успеха «плохая» ветка убивается, «хорошая» — мерджится. А в основной репозиторий попадает только результат.
В моей практике были случаи, когда один подход не срабатывал, я пытался реализовать ту же функциональность иначе. Так у меня существовали две параллельные ветки для одной и той же фичи. В случае успеха «плохая» ветка убивается, «хорошая» — мерджится. А в основной репозиторий попадает только результат.
История, что в svn, что в hg/git такая, какую сделаешь. Может вы не в курсе, но в svn тоже есть ветви :) Правда работа с ними очень неудобна по сравнению с hg/git.
Субъективные преимущества веток:
— возможность работать над несколькими задачами параллельно (даже если один работаешь — есть большой таск, над которым работаешь, но вдруг внезапно нужно сделать хотфикс, а код в неработоспособном состоянии)
— иметь «сборки» приложения созданные из разных наборов фич (например у нас есть три сервера: дев, тест (правильней бы было назвать его стэйдж, но так исторически сложилось) и продакшен. Разработка ведётся на дев, на тестовый выкладываются (путем мержа с ветками фич) фичи для тестирования заказчиком, а одобренные им фичи (это не все) выкладываются на продакшен (путем мержа с ветками фич). Попробуйте при линейной истории сделать простым способом такой сценарий: реализуются две фичи, изменяющие одни части приложения (каждая фича из нескольких коммитов, коммты фич чередуются), даются посмотреть заказчику, он говорит «вторую внедряем, а первую надо ещё долго дорабатывать».
Субъективные преимущества веток:
— возможность работать над несколькими задачами параллельно (даже если один работаешь — есть большой таск, над которым работаешь, но вдруг внезапно нужно сделать хотфикс, а код в неработоспособном состоянии)
— иметь «сборки» приложения созданные из разных наборов фич (например у нас есть три сервера: дев, тест (правильней бы было назвать его стэйдж, но так исторически сложилось) и продакшен. Разработка ведётся на дев, на тестовый выкладываются (путем мержа с ветками фич) фичи для тестирования заказчиком, а одобренные им фичи (это не все) выкладываются на продакшен (путем мержа с ветками фич). Попробуйте при линейной истории сделать простым способом такой сценарий: реализуются две фичи, изменяющие одни части приложения (каждая фича из нескольких коммитов, коммты фич чередуются), даются посмотреть заказчику, он говорит «вторую внедряем, а первую надо ещё долго дорабатывать».
Попробуйте внедрить у себя hg (с интерфейсом Tortoise Hg. Получите все преимущества распределённой системы контроля версий и довольно интуитивный графический интерфейс.
с консолью плотно совсем необязательно дружить. полно графических клиентов для Git'a — TortoiseGit, SmartGit
логика работы там не сильно отличается, это по-прежнему система контроля версий. С SVN на Git я перешел без проблем, единственное, понадобилось некоторое время на привыкание, что после комита, нужно делать push, чтобы изменения реально попали на сервер.
логика работы там не сильно отличается, это по-прежнему система контроля версий. С SVN на Git я перешел без проблем, единственное, понадобилось некоторое время на привыкание, что после комита, нужно делать push, чтобы изменения реально попали на сервер.
На TortoiseGit вроде многие ругаются, что он слишком SVN-шный.
Лучше SourceTree
Лучше SourceTree
Торвальдс разрабатывает linux. Остальные проекты на git разрабатываются централизовано. Из-за этого разница между ними оказывается не такой уж большой. Мне кажется, что svn вполне может перенять многие хорошие стороны git'a. Просто на это уйдет не один год с его текущими темпами разработки.
Первое большое отличие состоит в том, что в git'e используются локальные ветки для работы над несколькими изменениями одновременно. В svn'e для этого приходится плодить рабочие копии. В git'e существенно легче переключаться между веткой релиза и транком и портировать изменения из транка в релиз (особенно если между транком и релизом несколько тысяч ревизий, как в Chrome). Протокол git'a позволяет быстрее обновлять рабочую копию, чему помогает тот факт, что все файлы в рабочей копии всегда имеют одинаковую ревизию.
Большой недостаток git'a — не возобновляемый начальный чекаут. Если, вы, например, скачивайте исходники андроида через wifi, готовьтесь к тому, что гигабайтные репозитории придется скачать десяток раз из-за разрывов соединения. Я с ужасом жду дня, когда основой репозиторий Chrome переведут на git и объединят с репозиторием Blink'a.
У svn'а есть в чем-то аналогичный недостаток — если update зависнет (вообще говоря соединение должно разрываться по таймауту, указанному в настройках, но видимо из-за ошибок этого иногда не происходит) и будет прерван по ctrl+C, то придется делать svn cleanup который может работать по часу на гигабайтных репозиториях. Важно еще использовать 64-битный svn, иначе у svn cleanup может закончиться адресное пространство. Но по крайней мере svn cleanup не зависит от сети.
Первое большое отличие состоит в том, что в git'e используются локальные ветки для работы над несколькими изменениями одновременно. В svn'e для этого приходится плодить рабочие копии. В git'e существенно легче переключаться между веткой релиза и транком и портировать изменения из транка в релиз (особенно если между транком и релизом несколько тысяч ревизий, как в Chrome). Протокол git'a позволяет быстрее обновлять рабочую копию, чему помогает тот факт, что все файлы в рабочей копии всегда имеют одинаковую ревизию.
Большой недостаток git'a — не возобновляемый начальный чекаут. Если, вы, например, скачивайте исходники андроида через wifi, готовьтесь к тому, что гигабайтные репозитории придется скачать десяток раз из-за разрывов соединения. Я с ужасом жду дня, когда основой репозиторий Chrome переведут на git и объединят с репозиторием Blink'a.
У svn'а есть в чем-то аналогичный недостаток — если update зависнет (вообще говоря соединение должно разрываться по таймауту, указанному в настройках, но видимо из-за ошибок этого иногда не происходит) и будет прерван по ctrl+C, то придется делать svn cleanup который может работать по часу на гигабайтных репозиториях. Важно еще использовать 64-битный svn, иначе у svn cleanup может закончиться адресное пространство. Но по крайней мере svn cleanup не зависит от сети.
Это что — то вроде Intellij против Netbeans.
Git дает бешеное удобство и гибкость при разработке. Например git stash, возможность иметь branch-per-task (конечно же с постоянными сливами в мастер). А самый хороший пример я вижу сейчас, когда начал работать в новой фирме, где есть Team City + SVN. Я должен ждать пока пробегут все тесты на precommit, чтобы продолжить работать над теми же файлами, когда в Git я бы просто сделал push в remote и продолжил спокойно работать.
Надеюсь в ближайшем времени таки убедить начальство перейти на git.
Git дает бешеное удобство и гибкость при разработке. Например git stash, возможность иметь branch-per-task (конечно же с постоянными сливами в мастер). А самый хороший пример я вижу сейчас, когда начал работать в новой фирме, где есть Team City + SVN. Я должен ждать пока пробегут все тесты на precommit, чтобы продолжить работать над теми же файлами, когда в Git я бы просто сделал push в remote и продолжил спокойно работать.
Надеюсь в ближайшем времени таки убедить начальство перейти на git.
Спасибо вам, таки наверное пора уже начинать пользоваться системами контроля версий.
Repl для ruby:
IRB и PRY
IRB и PRY
Полезная статья. Поразительно, что кто-то до сих пор не использует системы контроля версий. Джоэл ещё в 2000 призывал их использовать, git скоро 9 лет.
Что планируете на следующую статью? Предлагаю системы непрерывной интеграции и юнит-тестирование.
Что планируете на следующую статью? Предлагаю системы непрерывной интеграции и юнит-тестирование.
Скорее всего три-четыре пункта. Обязательно будет что-то из этого:
— Инструменты для тестирования — пожалуй самая полезная штука, после систем контроля версий. Мне очень понравился подход TDD, но обычно я вручную писал мини-надстройку для автоматизации тестов.
— Библиотеки (+API, +Фреймворки), удивительно, но многие до сих пор предпочитают написать что-то ручками, чем залезть в документацию по стандартной библиотеке или использовать какой-нибудь сторонний пакет
— Отладчики — все знают, что они есть, но когда наступает момент истины, используют аналоги бубна.
— Системы баг-трекинга — просто полезная штука
— Инструменты статического анализа кода (привет, PVS Studio!)
Ну а по-поводу систем непрерывной интеграции… Это хорошая штука, но подойдет ли она тем, кто придерживается традиционного цикла разработки? Все-таки при использовании некоторых методологий разработки непрерывная интеграция невозможна, неудобна, ненужна или еще что-то.
А так да, я напишу и про нее, только в 3-ей или 4-ой части цикла.
— Инструменты для тестирования — пожалуй самая полезная штука, после систем контроля версий. Мне очень понравился подход TDD, но обычно я вручную писал мини-надстройку для автоматизации тестов.
— Библиотеки (+API, +Фреймворки), удивительно, но многие до сих пор предпочитают написать что-то ручками, чем залезть в документацию по стандартной библиотеке или использовать какой-нибудь сторонний пакет
— Отладчики — все знают, что они есть, но когда наступает момент истины, используют аналоги бубна.
— Системы баг-трекинга — просто полезная штука
— Инструменты статического анализа кода (привет, PVS Studio!)
Ну а по-поводу систем непрерывной интеграции… Это хорошая штука, но подойдет ли она тем, кто придерживается традиционного цикла разработки? Все-таки при использовании некоторых методологий разработки непрерывная интеграция невозможна, неудобна, ненужна или еще что-то.
А так да, я напишу и про нее, только в 3-ей или 4-ой части цикла.
А я вот наблюдаю какую-то другую тенденцию:
Никак не могу переубедить, заставить что-то выучить.
Увидели статью про multi cursors — «это хрень какая-то. На нашем проекте нельзя, запретить! А то ща что-нибудь наделают. Я бы такому девелоперу… бла бла бла...»
- Я так делал 2 (3, 5, 7) лет назад и по-другому не буду. Нафиг мне это всё нужно.
- Профилировщики/Сонары/Анализаторы — это мне не нужно, я и так знаю, что я пишу
- От опытного (10+ лет) ресурс/проджект менджера/тех. лида: программист не должен знать/уметь работать с системами контроля версий, он должен уметь писать код. Кнопку нажал и готово. Зачем тратить время на изучение этих систем, только база: как сделать commit/push/branch
- Как следствие предыдущего пункта: git. Я уже всё запушил, а потом закоммитал, забирайте.
Никак не могу переубедить, заставить что-то выучить.
Увидели статью про multi cursors — «это хрень какая-то. На нашем проекте нельзя, запретить! А то ща что-нибудь наделают. Я бы такому девелоперу… бла бла бла...»
Ух и нелегко Вам!
Я обычно натыкался на простые отмазки, вроде «мне лень», «мне это не нужно», «мне надо работать», «начну использовать в следующем проекте» и другое.
Позволю себе прокомментировать Ваши наблюдения:
Ну это совсем просто. Все знают, что программисту нужно постоянно учиться. Да что там, в любом виде деятельности необходимо постоянно быть открытым новому. Ну а парировать «Нафиг мне это нужно», наверное невозможно.
Профилирование — как автодополнение, оно не призвано заменить разработчику мозг, оно помогает ему работать быстрее и с удобством.
А вот тут я почему-то согласен с опытным кем-то. Если программист достаточно разбирается в гит (заменить на свою СКВ) и у него есть более интересные направления развития, то почему-бы и нет? Время наше ограничено и если бы мне дали выбор — выучить досконально git или выучить досконально lisp, я бы выучил лисп.
Однако, нужно заметить, что если работа напрямую не связанна с lisp'ом, но связанна с гитом, то куда полезнее было бы разобраться в гите.
А вот тут — надо учиться.
Понимаю Вас, однако, зачем вам кого-то переубеждать, вспомните, может Вы сами относитесь также к чему-либо? Скажем я уже который год не могу разобраться с веб-разработкой, даже не пробовал ничего, кроме node.js и чувствую, что дело просто в страхе перед чем-то новым.
Это действительно было так?
Я обычно натыкался на простые отмазки, вроде «мне лень», «мне это не нужно», «мне надо работать», «начну использовать в следующем проекте» и другое.
Позволю себе прокомментировать Ваши наблюдения:
Я так делал 2 (3, 5, 7) лет назад и по-другому не буду. Нафиг мне это всё нужно.
Ну это совсем просто. Все знают, что программисту нужно постоянно учиться. Да что там, в любом виде деятельности необходимо постоянно быть открытым новому. Ну а парировать «Нафиг мне это нужно», наверное невозможно.
Профилировщики/Сонары/Анализаторы — это мне не нужно, я и так знаю, что я пишу
Профилирование — как автодополнение, оно не призвано заменить разработчику мозг, оно помогает ему работать быстрее и с удобством.
От опытного (10+ лет) ресурс/проджект менджера/тех. лида: программист не должен знать/уметь работать с системами контроля версий, он должен уметь писать код. Кнопку нажал и готово. Зачем тратить время на изучение этих систем, только база: как сделать commit/push/branch.
А вот тут я почему-то согласен с опытным кем-то. Если программист достаточно разбирается в гит (заменить на свою СКВ) и у него есть более интересные направления развития, то почему-бы и нет? Время наше ограничено и если бы мне дали выбор — выучить досконально git или выучить досконально lisp, я бы выучил лисп.
Однако, нужно заметить, что если работа напрямую не связанна с lisp'ом, но связанна с гитом, то куда полезнее было бы разобраться в гите.
Как следствие предыдущего пункта: git. Я уже всё запушил, а потом закоммитал, забирайте
А вот тут — надо учиться.
Никак не могу переубедить, заставить что-то выучить.
Понимаю Вас, однако, зачем вам кого-то переубеждать, вспомните, может Вы сами относитесь также к чему-либо? Скажем я уже который год не могу разобраться с веб-разработкой, даже не пробовал ничего, кроме node.js и чувствую, что дело просто в страхе перед чем-то новым.
Увидели статью про multi cursors — «это хрень какая-то. На нашем проекте нельзя, запретить! А то ща что-нибудь наделают. Я бы такому девелоперу… бла бла бла...»
Это действительно было так?
Это действительно было так?
Очень негативно восприняли такие возможности.
Мол, ничего хорошего от этого ждать не приходится. Ща поменяет лишний курсор строчку где не надо и на проде всё ляжет…
Вообще, я даже смирился, пусть делают как хотят/как им удобнее.
Лично я испытываю настоящее наслаждение, когда немного подучил эту фишку и уже активно ею пользуюсь.
Что-то в скрипте/коде поменять можно в 5-10 нажатий на клаве, а не Find&Replace->Set Regexp Mode-> [write regexp -> replace one -> ctrl+z -> fix regexp].many-times -> replace-all with regexp.
Подозреваю, что автор имел ввиду gprof, а не gperf. Gperf вроде как ничего не профилирует, просто хеши генерирует ;)
для отладки приложения после каждой строчки вставляли print
Регулярно так делаю (правда не print, а trace), и не знаю, чем заменить.
Всё зависит от конкретной ситуации. Если качество (и ясность/простота) кода достаточно высокое, багов в нём мало, и print-ами они обнаруживаются за несколько минут — нет никаких причин избегать этих print-ов (более того, обычно в таких случаях ловить баг через отладчик будет заметно дольше и сложнее). А если код запутан и малопонятен, то ловить баг в отладчике скорее всего будет намного быстрее и эффективнее чем print-ами.
В целом — согласен. IDE-отладчиками тоже иногда пользуюсь, но у них есть некоторые недостатки:
— Нужен IDE.
— Не все можно посмотреть, а особенно вычислить (особенно в компилируемых средах).
— Когда происходит останов по брекпоинту, трудно сразу понять в какой именно вызов процедуры это произошло (нужно поднимать стек и прочий контекст), а если функция вызывается постоянно из многих частей программы — то выловить нужный вызов — большое искусство.
— При отладке циклов — не так то легко добраться до ошибочной итерации — приходится на брекпоинты вешать условия, и заниматься прочими танцами с бубнами.
— Бывают случаи, когда важно все выполнить в реальном времени
С другой стороны, точно и грамотно поставленные вызовы трассировки на разных уровнях формируют протокол, по которому сразу становится ясной ПОЛНАЯ картина происходящего в системе. На трассировку можно ставить условия, вызывать ее в циклах, добираться до всего до чего можно дотянуться — в общем развлекаться как хочешь. Кроме того, вся работа в отладчике после отладки исчезает, не оставляя следов. Вызовы же трассировки можно либо оставлять (заглушая саму функцию трассировки), либо комментировать. В любом случае — остаются некие результаты.
— Нужен IDE.
— Не все можно посмотреть, а особенно вычислить (особенно в компилируемых средах).
— Когда происходит останов по брекпоинту, трудно сразу понять в какой именно вызов процедуры это произошло (нужно поднимать стек и прочий контекст), а если функция вызывается постоянно из многих частей программы — то выловить нужный вызов — большое искусство.
— При отладке циклов — не так то легко добраться до ошибочной итерации — приходится на брекпоинты вешать условия, и заниматься прочими танцами с бубнами.
— Бывают случаи, когда важно все выполнить в реальном времени
С другой стороны, точно и грамотно поставленные вызовы трассировки на разных уровнях формируют протокол, по которому сразу становится ясной ПОЛНАЯ картина происходящего в системе. На трассировку можно ставить условия, вызывать ее в циклах, добираться до всего до чего можно дотянуться — в общем развлекаться как хочешь. Кроме того, вся работа в отладчике после отладки исчезает, не оставляя следов. Вызовы же трассировки можно либо оставлять (заглушая саму функцию трассировки), либо комментировать. В любом случае — остаются некие результаты.
Какой-то это детский сад.
Если программист про контроль версий не знает — его к проекту допускать нельзя, это элементарный уровень.
Профилировщик почему-то на втором месте, но тема не раскрыта совершенно.
REPL хорош для скриптовых языков, для чего-то с более-менее сложным синтаксисом он уже не особенно интересен.
Если программист про контроль версий не знает — его к проекту допускать нельзя, это элементарный уровень.
Профилировщик почему-то на втором месте, но тема не раскрыта совершенно.
REPL хорош для скриптовых языков, для чего-то с более-менее сложным синтаксисом он уже не особенно интересен.
Заведя репозиторий на каком-нибудь сервисе, вроде github, bitbcket или sourceforge у Вас будет бесплатный бекап на надежном внешнем сервере
Don't drink too much Kool-Aid. По запросу «egor homakov gihub» гугл рассказывает страшные истории. Кроме того (кому-то это может быть действительно важно), GitHub находится в юрисдикции США. А вот, например, Gitorious — нет. Ну а свой собственный сервер и вовсе можно практически в любой возможной юрисдикции заиметь.
Don't drink too much Kool-Aid. По запросу «egor homakov gihub» гугл рассказывает страшные истории. Кроме того (кому-то это может быть действительно важно), GitHub находится в юрисдикции США. А вот, например, Gitorious — нет. Ну а свой собственный сервер и вовсе можно практически в любой возможной юрисдикции заиметь.
Всвязи с чем Вы написали возле Git — «выберите его!», если Mercurial — «по многим параметрам лучше Git»? :)
По каким параметрам?
Вы сможете меня убедить перейти на hg?
Правда, без подтекста и намёка на холивар спрашиваю. Сколько раз хотел услышать внятные комментарии, где бы на пальцах объяснили.
И тот, и другой — хороши. Если у вас есть серьёзный опыт и там, и там — расскажите про «hg лучше git»
Вы сможете меня убедить перейти на hg?
Правда, без подтекста и намёка на холивар спрашиваю. Сколько раз хотел услышать внятные комментарии, где бы на пальцах объяснили.
И тот, и другой — хороши. Если у вас есть серьёзный опыт и там, и там — расскажите про «hg лучше git»
Это я писал, что Mercurial лучше Git по многим параметрам.
И я смогу Вас убедить перейти на hg, но не буду этого делать, оставайтесь на Git!
Окей, быстро и на пальцах, плюсы hg, по сравнению с git:
1. hg на один символ короче, чем git. Я серьезно.
2. В hg меньше команд, чем в git. Для минималиста это плюс.
3. git более популярен, чем hg. Благодаря, чему, зная hg, можно почувствовать себя уникальной личностью на тусовке фанатов git'а.
4. hg ведет двойную нумерацию ревизий (вместе с хешем, нумерует их по-порядку).
5. У git нет API (только делать каждый раз fork-exec)
6. В git нет хуков.
7. В hg намного рациональнее организованы команды.
8. revsets
9. hg incoming
10. hg grep
Пальцы, кончились.
Ну и напоследок:
Есть конечно доля шутки во всем этом, но hg действительно по многим показателям намного лучше, чем git.
Однако я использую git.
И я смогу Вас убедить перейти на hg, но не буду этого делать, оставайтесь на Git!
Правда, без подтекста и намёка на холивар спрашиваю. Сколько раз хотел услышать внятные комментарии, где бы на пальцах объяснили.
И тот, и другой — хороши. Если у вас есть серьёзный опыт и там, и там — расскажите про «hg лучше git»
Окей, быстро и на пальцах, плюсы hg, по сравнению с git:
1. hg на один символ короче, чем git. Я серьезно.
2. В hg меньше команд, чем в git. Для минималиста это плюс.
3. git более популярен, чем hg. Благодаря, чему, зная hg, можно почувствовать себя уникальной личностью на тусовке фанатов git'а.
4. hg ведет двойную нумерацию ревизий (вместе с хешем, нумерует их по-порядку).
5. У git нет API (только делать каждый раз fork-exec)
6. В git нет хуков.
7. В hg намного рациональнее организованы команды.
8. revsets
9. hg incoming
10. hg grep
Пальцы, кончились.
Ну и напоследок:
% git add
Nothing specified, nothing added.
Maybe you wanted to say 'git add .'?
Есть конечно доля шутки во всем этом, но hg действительно по многим показателям намного лучше, чем git.
Однако я использую git.
Дело привычки.
hg как-то компактнее, что ли. И потому почти всего его команды натягиваются на гуй, и получается весьма достойно (TortoiseHG например).
В git приходится использовать консоль.
В целом то ничего страшного в этом нет. Но иногда с визуальным представлением и мышью сделать что-нибудь выходит быстрее, чем с консолью.
hg как-то компактнее, что ли. И потому почти всего его команды натягиваются на гуй, и получается весьма достойно (TortoiseHG например).
В git приходится использовать консоль.
В целом то ничего страшного в этом нет. Но иногда с визуальным представлением и мышью сделать что-нибудь выходит быстрее, чем с консолью.
Ну и в некоторых (всех?) дистрах поддержка меркуриал получше чем у гит — автодополнение из коробки куда более интеллектуальное.
не согласен я с вами по поводу того, что мышью выходит быстрее. Пользоваться консолью зачастую намного удобнее и быстрей, чем пользоваться GUI.
Ну, не холивара ради…
Вы сами тут употребили слово «зачастую». А это значит «не всегда». Так что дискутировать просто не о чем.
Вы сами тут употребили слово «зачастую». А это значит «не всегда». Так что дискутировать просто не о чем.
Есть сугубо «гуйные» задачи. Где вообще сложно что-то сделать с помощью консоли (та же ретушь фотографий, например).
В системе контроля версий просмотр и работа с ветвями, а также отчасти слияние и разрешение конфликтов
В системе контроля версий просмотр и работа с ветвями, а также отчасти слияние и разрешение конфликтов
Для hg существует очень удобная и полностью бесплатная графическая оболочка — TortoiseHg. Для нас это стало решающим фактором.
Я имел ввиду «По многим параметрам Mercurial лучше, чем Git, а многим — хуже».
И я хочу, чтобы люди выбирали Git, не потому, что он лучше, чем все остальные системы, а потому-что мне нравится Git.
Надеюсь Вам стало понятнее.
И я хочу, чтобы люди выбирали Git, не потому, что он лучше, чем все остальные системы, а потому-что мне нравится Git.
Надеюсь Вам стало понятнее.
как-то странно получается. Судя по Вашим словам, Вы предлагаете людям Git не обосновывая чем он лучше остальных систем, и опять же напиписали что Mercurial лушче, так уж расписали бы тогда в чем именно он лучше. Если считаете что по каким-то параметрам он проигрывает Git — тоже уточнили бы, а то в посте про это не слово.
Мне кажется это было правильно. Это конено же не пост, ориентированный на сравнивание тех или иных систем контроля версий, но раз уж вы приводите их несколько штук и даже берете на себя смелость какую-то из этих систем настойчиво рекомендовать — нужно обязательно указывать все плюсы и минусы, которые будут давать понять почему именно следуют выбрать именно эту систему, а не какую другую. Если расписывать лень, можно было бы хоть ссылку вставить на какой-нибудь пост, где есть сравнения (если Ваша точка зрения совпадает с той, которая изложена в указываемом посте).
Мне кажется это было правильно. Это конено же не пост, ориентированный на сравнивание тех или иных систем контроля версий, но раз уж вы приводите их несколько штук и даже берете на себя смелость какую-то из этих систем настойчиво рекомендовать — нужно обязательно указывать все плюсы и минусы, которые будут давать понять почему именно следуют выбрать именно эту систему, а не какую другую. Если расписывать лень, можно было бы хоть ссылку вставить на какой-нибудь пост, где есть сравнения (если Ваша точка зрения совпадает с той, которая изложена в указываемом посте).
Возможно. Как вы предлагаете исправить ситуацию сейчас?
Ввиду того что люди постоянно мечутся между git и mercurial, то стоит хотя бы вкратце описать основные достоинства и недостатки этих систем по сравнению друг с другом. И обосновать Ваше желание сделать упор именно на Git.
Именно, хочу уйти с SVN, вот сейчас вообще не понял что выбрать… Git или Mercurial… До этого хотел Git, теперь засомневался…
Вспомнилась книга:
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру
REPL
Почему-то не вижу особого смысла для C++:
>>Для проверки какой-либо конструкции языка или его возможности Вы создаете полноценное тестовое приложение.
Если задача состоит в том, чтобы сделать какой-то эксперимент, можно сделать это в виде юнит-теста, у Вас ведь есть существующая инфраструктура для юнит-тестов? Такой подход даст возможность без особого труда поиграться с объектной структурой Вашего приложения. Ну а если нужно написать какой-то тест для проверки производительности чего-либо, то тут уже не обойтись без отдельного тестового приложения.
>>Для вычисления значения какого-либо сложного выражения, Вы долго мучаетесь с калькулятором…
Калькулятор на C++, а смысл? Думаю проще воспользоваться другими средствами.
Почему-то не вижу особого смысла для C++:
>>Для проверки какой-либо конструкции языка или его возможности Вы создаете полноценное тестовое приложение.
Если задача состоит в том, чтобы сделать какой-то эксперимент, можно сделать это в виде юнит-теста, у Вас ведь есть существующая инфраструктура для юнит-тестов? Такой подход даст возможность без особого труда поиграться с объектной структурой Вашего приложения. Ну а если нужно написать какой-то тест для проверки производительности чего-либо, то тут уже не обойтись без отдельного тестового приложения.
>>Для вычисления значения какого-либо сложного выражения, Вы долго мучаетесь с калькулятором…
Калькулятор на C++, а смысл? Думаю проще воспользоваться другими средствами.
К упомянутому выше ещё причины не добавлять что-то новое:
— зачастую эффективность новых инструментов низка, а то и отрицательна без грамотной настройки (читай — развитых навыков администрирования) и правильного понимания когда их нужно применять, а когда нет, а в штатной документации ничего нет о лучших практиках, а нештатные могут утверждать противоположные вещи и/или не описывать условия применимости (пример: различные воркфлоу гита — система принятая при разработке линукса может оказаться избыточной, а значит неэффективной, если разработчик один)
— затрудненность выбора: хочется использовать лучший инструмент, а рынок предлагает несколько, времени на освоение всех до компетентного уровня нет, а информация противоречива (холивары :) или различия неясны
— практически неизбежное снижение эффективности на первых порах без получения немедленных плюсов (простой пример: внедрили вкс, но история идёт линейно и откатов не производится — зачем она нужна? Или тесты: покрыли код, а они никогда не валятся)
— зачастую эффективность новых инструментов низка, а то и отрицательна без грамотной настройки (читай — развитых навыков администрирования) и правильного понимания когда их нужно применять, а когда нет, а в штатной документации ничего нет о лучших практиках, а нештатные могут утверждать противоположные вещи и/или не описывать условия применимости (пример: различные воркфлоу гита — система принятая при разработке линукса может оказаться избыточной, а значит неэффективной, если разработчик один)
— затрудненность выбора: хочется использовать лучший инструмент, а рынок предлагает несколько, времени на освоение всех до компетентного уровня нет, а информация противоречива (холивары :) или различия неясны
— практически неизбежное снижение эффективности на первых порах без получения немедленных плюсов (простой пример: внедрили вкс, но история идёт линейно и откатов не производится — зачем она нужна? Или тесты: покрыли код, а они никогда не валятся)
Сам я использую git, реже bazaar и Вам собственно советую начать с git.
…
Git (выберите его!)
Начинайте с Mercurial и забудьте про GIT как про страшный сон.
p.s.
Да, достаточно долго работал и с git и с hg(Mercurial).
Да, держал огромные репозитории продуктов в обоих.
Да, собирал из веток-фич релизы в обоих репозиториях.
Да, искал ветки, которые порождали баги.
Да, hg в этом плане лучше.
Да, в hg нет нативного stash
А ещё есть куча софта для проверки синтаксиса в набираемом тексте. Это я сейчас с намеком на ошибки (описки) в статье. А вообще, раздражает, когда код пишется неграмотно (пример: instans, instanse, chek и т.п). Яркий пример из HTTP протокола с заголовком referer. Подскажите, как с таким бороться в чужом коде?
UFO just landed and posted this here
Тематика очень полезная, но введение пока что неконкретное, да и небесспорное.
Скажем, про системы контроля версий вроде бы всё верно написано, но борясь с «велосипедами» вы предлагаете пользоваться чьими-то сторонними сервисами, которые в один миг могут ваш код вообще выкинуть на свалку. Я держу репозиторий на собственном сервере и перекидываю в него проекты только после этапа начального экспериментирования, потому что в первую неделю работы обычно происходят настолько массированные изменения, что возня с репозиторием просто не оправдывается.
Ну или про REPL. Напишите уж подробнее, я так и не понял до конца как можно прикрутить Cling к существующему проекту на Visual Studio, например. Ведь понятно, что REPL используется не в виде отдельной консоли, а при дебаге проекта, над которым я сейчас работаю.
Ну и на отладочную печать зря наехали. Керниган и Пайк, например, говорят, что печать куда лучше любого дебаггера. Я не готов занять такую экстремальную позицию, но примеров их правоты немало (в многопоточных программах, скажем).
Скажем, про системы контроля версий вроде бы всё верно написано, но борясь с «велосипедами» вы предлагаете пользоваться чьими-то сторонними сервисами, которые в один миг могут ваш код вообще выкинуть на свалку. Я держу репозиторий на собственном сервере и перекидываю в него проекты только после этапа начального экспериментирования, потому что в первую неделю работы обычно происходят настолько массированные изменения, что возня с репозиторием просто не оправдывается.
Ну или про REPL. Напишите уж подробнее, я так и не понял до конца как можно прикрутить Cling к существующему проекту на Visual Studio, например. Ведь понятно, что REPL используется не в виде отдельной консоли, а при дебаге проекта, над которым я сейчас работаю.
Ну и на отладочную печать зря наехали. Керниган и Пайк, например, говорят, что печать куда лучше любого дебаггера. Я не готов занять такую экстремальную позицию, но примеров их правоты немало (в многопоточных программах, скажем).
Я вот тащусь от «in-editor REPL». Использую Komodo IDE; они поддерживают javascript макросы, и вот в команде создали несколько макросов для исполнения выделенного фрагмента или всего файла. Несказанно удобно, не только для быстрого тестирования, а вот например нужно узнать charcode символа, и что бы не искать где-то в интернете пишем,
'a'.charCodeAt(0), выделяем, жмём hotkey и тут же результат вставляется в editor.Sign up to leave a comment.
Инструменты разработчика или Почему вы не используете X? Часть 1