• У вас есть синдром ученика?
    0

    Веб-мастерами их называли. Но суть та же, понемногу отовсюду и ничего на уровне программиста.

  • Почему нужно перестать использовать Git rebase
    0

    Очевидно, что тесты лучше, но если у вас их нет, то за 5 минут их не добавишь. Но это ж кем надо быть, чтобы убрать строку, не прочитав комментарий рядом с ней?


    я акцентировал внимание на том, что Ваше «зачем искать почему написано ТАК, если проще просто исправить» — неприменимо, ИМХО, к не-опечаткам

    Да, но не-опечатки крайне редко тесты проходят… А вот в к-н строке опечатка может проскочить. Поэтому это единственная вероятная ситуация, которая мне пришла в голову для случая, когда ошибка не обнаружилась во время rebase. Конечно, бывают и более хитрые случаи, но весьма редко.

  • Почему нужно перестать использовать Git rebase
    0
    Да-да, тестов на этом проекте нет

    Тогда можно комментарии хотя бы писать. А то что толку от вашей истории коммитов, если assert всё равно убрали не глядя?


    благодаря git bisect стало понятно кто и почему виноват и, главное, как это исправить

    git bisect будет так же работать и в случае с rebase, тут разницы то принципиальной нет. Просто, имхо, вы преувеличиваете, что необходимость в этом возникает чуть ли не ежедневно.

  • Почему нужно перестать использовать Git rebase
    –1

    Я не против цепочки коммитов (напр. рефакторинг, рефакторинг, первая логически атомарная часть фичи, вторая часть фичи и т.д.), но десятки, а тем более сотни — это просто организационный косяк, когда границы фичи вообще не определяют.

  • Почему нужно перестать использовать Git rebase
    0

    Если при ребейзе оставить чери-пикнутый коммит, то он просто покажет предупреждение типа "пустой коммит" и пропустит его автоматически. Но можно и скипнуть, не принципиально.

  • Почему нужно перестать использовать Git rebase
    0

    Да, деплой на staging лучше всё-таки с ручным управлением оставить. Чтобы тестировщики сами могли определять, какую ветку они в текущий момент тестируют и она не изменилась случайно, только из-за того, что новый PR пришёл.

  • Почему нужно перестать использовать Git rebase
    0

    Странная у Вас логика… Типа между версиями один автор мог закоммитить только 1 фичу?
    Рефакторинг — да, может затронуть много строк, но если делать 1 вид рефакторинга в 1 коммите (а это по сути и есть границы технической фичи), то никаких проблем не возникнет, вне зависимости от кол-ва затронутых строк.

  • Почему нужно перестать использовать Git rebase
    +1
    Нужно смёржить мастер в ветку, прогнать тесты, поправить код, сделать git commit --amend, а потом уже мёржить ветку в мастер.

    Ну вариант, да. Хотя лично для меня все эти мерджи master в ветку выглядят как какое-то дикое извращение.


    Вы вроде не выступаете за то, чтобы делать squash при мёрже?

    У меня нет строгого правила, что должен остаться обязательно 1 коммит, т.к. иногда удобнее сделать 3-5 коммитов в одной ветке, чем дробить это на 3-5 минифич. Но ветки по 100 коммитов, или как тут писали на 10000 значимо измененных строк, я не одобряю.


    Видимо под удобной в работе историей вы имеете в виду линейную. Чем она удобна? В чём преимущество перед нелинейной?

    Ну тут имхо очевидно. Что может быть проще прямой линии? Всё красиво и откатывать при необходимости можно фичи целиком, а не по 100 коммитов. Зачем засорять себе восприятие какими-то коммитами, которых по факту никогда не было в master? Чтобы найдя к-н опечатку вооружиться git bisect в поисках коммита, в котором она была сделана? Чтобы что? Чтобы revert сделать? А если там ещё изменения есть кроме той опечатки… И эти все пляски с бубном вместо того, чтобы за пару секунд исправить опечатку и закоммитить исправление? Или это так важно найти кто виноват и оштрафовать его на ползарплаты?

  • Почему нужно перестать использовать Git rebase
    +2

    Ну, можно для начала CI настроить с прогоном тестов на каждый коммит (в любую ветку).

  • Почему нужно перестать использовать Git rebase
    +1

    Думаете, разбиение этого патча на 500 коммитов сильно упростит ревью?
    Может просто не надо такие монструозные ветки делать?

  • Почему нужно перестать использовать Git rebase
    0
    Зачем делать эту тривиальнейшую процедуру, если её можно и не делать?

    Чтобы не было битых коммитов и чтобы была удобная в работе история коммитов.


    Откуда им взяться в случае c merge?

    Оттуда что сначала идёт merge, а потом уже проверка. И, как тут уже писали, придётся доп.коммит с исправлениями после merge делать.

  • Почему нужно перестать использовать Git rebase
    +7

    Повторный rebase — это тривиальнейшая процедура, уже без конфликтов в 99% случаев. Зато в master не будет ни одного битого (с т.з. тестов) коммита, а в случае с merge их так просто не избежать.
    Главный аргумент статьи провалился из-за банального непонимания автора как правильно делать rebase. Из "бонусов" merge остались только уродливые merge-коммиты из master в ветку и обратно, которые типо интересно кому-то будет смотреть.

  • Почему нужно перестать использовать Git rebase
    +3

    Из комментариев уже понял… Только это никаких проблем при использовании rebase не вызывает. Т.к. никто в здравом уме не будет вливать ветку после rebase до того как она пройдёт все тесты.

  • Почему нужно перестать использовать Git rebase
    +3

    Другими словами, в случае rebase это обнаружится до вливания ветки в master, а в случае с merge — после. Вот и приехали.

  • Почему нужно перестать использовать Git rebase
    +4

    Статью то я читал… только она о каких-то вымышленных проблемах, которые мне за 8 лет использования rebase ни разу не встретились… Потому что по факту после rebase у вас остаётся всё такая же отдельная ветка, на которой вы всё так же запускаете тесты, и если что-то поломалось, то сначала выясняете в чём проблема, исправляете её, делаете ещё раз ребейз (начиная со второго раза это всегда легко), прогоняете тесты ещё раз, и убедившись, что всё работает, вливаете эту ветку в master.
    Таким образом, битые коммиты после ребейз теоретически возможны, если прокралась какая-то ошибка, которая: 1) не мешает компиляции и запуску проекта; 2) не отлавливается тестами. Впрочем, сюрприз, такую ошибку вы и после merge ещё не скоро заметите. Только с линейной историей отследить и исправить её будет гораздо легче, вот и вся разница.


    P.S. Ребейз всегда делается интерактивный, ума ни приложу, кому и зачем может захотететься запустить его в неинтерактивном режиме.

  • Почему нужно перестать использовать Git rebase
    –2

    И squash и fixup вполне могут добавить осмысленности, Вы просто в каких-то розовых облаках витаете, где каждый коммит в рабочей ветке идеально продуман, логически выверен и не имеет ни единой опечатки. Отсюда и связь с водопадом, потому что на практике такое корпение над каждым коммитом в рабочей ветке — это пустая трата времени.
    Объединение всех коммитов фичи в 1 — иногда оправдано, иногда — нет, но в целом если в ветке после rebase осталось больше 7 коммитов, то у вас что-то не так с определением границ фич.

  • Почему нужно перестать использовать Git rebase
    +4
    после ребейза запустим тесты, увидим, что код сломан, и поправим в том коммите, где сломалось. Ребейз надо делать не один раз, а столько, сколько надо для достижения результата.

    Вот, кстати, да. Статья написана так, как-будто после rebase ветка сразу объединяется с master, хотя по факту (при адекватной разработке) слияние будет только после прохождения тестов в ребейзнутой ветке.

  • Почему нужно перестать использовать Git rebase
    +2

    Вот для их осмысления и существует rebase. Или вы к модели водопада предлагаете вернуться?

  • Почему нужно перестать использовать Git rebase
    +14

    Вот-вот… Сначала что-то монструозное пилят в отдельной ветке полгода, без единого ребейза на master… А потом rebase виноват в том, что надо несколько часов потратить на него для сохранения нескольких сотен коммитов :-)

  • Почему нужно перестать использовать Git rebase
    +4
    Допустим, мы удалили из master зависимость, которая всё ещё используется в feature. 

    Это что имеется в виду? Удалили коммит из master, серьёзно?


    Решение конфликтов посреди rebase длинной цепочки коммитов часто превращается в непростую задачу

    Абсолютно эквивалентную по сложности решению конфликтов при merge большой ветки.


    Для этого мы могли бы использовать интерактивный rebase.

    Кхм, а кто-то реально использует неинтерактивный?


    P.S. Вся статья — какая-то голая риторика, без единого практически значимого аргумента. То, что по время rebase можно допустить ошибку — это не проблема rebase, такую же ошибку можно и во время merge допустить.

  • Разработка прибыльной Android игры двумя школьниками
    0

    Вы для начала заработайте своим приложением больше 2 млн. © ст.171 УК РФ, а потом уже следователей начинайте бояться xD
    Хотя возможна и обратная ситуация, можно, имея ИП, попасть под ст.198 УК РФ "Уклонение физического лица от уплаты налогов", если вы продажу лицензий на приложение пытаетесь выдать за предпринимательскую деятельность.

  • Я б в программеры пошёл, пусть меня научат
    +1
    if / господи, как же пишется if на паскале?, забыл уже всё… /

    if (i mod 2 = 0) then
      ...
  • Я б в программеры пошёл, пусть меня научат
    0

    А у нас в школе в начале 2000-х не было интернета, а был как раз Бейсик-Агат. В 11-м классе правда поставили новые компы и перешли на QBasic.
    Но по сути, я начал программировать c Object Pascal уже в универе.

  • Я б в программеры пошёл, пусть меня научат
    +5

    Можно с C# начать, тогда можно не месяц, а хоть целый год ему посвятить. Языки с динамической типизацией, имхо, нельзя новичкам давать.

  • Разработка прибыльной Android игры двумя школьниками
    0

    Ну на тему работы с AppStore как физ.лицо есть целая статья с комментариями юристов. Думаю, для PlayMarket те же положения по авторскому праву будут иметь силу.
    Но я отвечал не на эту часть сообщения belator… И процитированная часть насчёт связи НДФЛ с отчислениями в фонды — это точно полный бред с т.з. НК РФ.

  • Go: 10 лет и растём дальше
    +1

    На Elixir:


    1..10000 
    |> Enum.map(&Task.async(fn ->
      IO.puts("worker #{&1} started job")
      :timer.sleep(1000)
      IO.puts("worker #{&1} finished job")
    end))
    |> Enum.map(&Task.await/1)
  • Разработка прибыльной Android игры двумя школьниками
    +1
    Даже если это можно было бы как-то квалифицировать как НДФЛ, то отчисления в пенсионный фонд и на медстрахование никто не отменял.

    Вам бы самому налоговый кодекс почитать, прежде чем советы давать… Отчисления в пенсионный фонд и на медстрахование платят юр.лица за штатных сотрудников и ИП.
    Физ.лица платят только НДФЛ со своих доходов. Как пример, договор подряда не подразумевает никаких отчислений в фонды.

  • Не рычите на фрилансера
    +1

    Если со стороны заказчика смотреть, то по сравнению с наймом компании 1000 руб/час — это очень-очень дешево. Такие расценки были лет 7 назад у региональных компаний на саппорт сайтов уровня корпоративный/визитка, при этом по факту выделяется время обычного программиста средней руки. Так что по нынешним меркам, чтобы нанять через компанию сеньора с зарплатой 160-180к платить придётся ближе к 5000 руб/час, иначе компания разорится )))

  • Правда ли, что люди пишут безумный код с перекрывающимися побочными эффектами, сохраняя при этом невозмутимость?
    +1

    zeitweilig куда как более популярное прилагательное в немецком.

  • Chrome победил
    0

    По StatCounter, на который статья опирается, доля винды на десктопе сейчас — 84%.

  • Chrome победил
    0

    Хотя поправлюсь, экспоненту можно применить, но не так как автор, а как для нормального распределения.

  • Chrome победил
    +1

    Да какие могут быть обоснования для выбора экспоненты, когда есть потолок в 100%? График неизбежно даже от логарифма будет отставать, хотя текущий интервал можно им аппроксимировать.

  • BDD — рабочий метод или TDD в модной обертке?
    0

    Имхо, BDD было модным словом лет 7-8 назад…
    А по отличиям всё просто: есть такая штука, функциональная спецификация называется, это документ, согласно которому составляется тест-план приёмочного тестирования. BDD призван автоматизировать этот процесс.
    А TDD работает на уровне юнит-тестов, т.е. помогает продумывать детали реализации и отлавливать ошибки на этом уровне.

  • Почему ненавидеть код-ревьюера – хорошо
    +2
    change-request из-за отсутствия пустой строки в конце файла

    Это либо принято за правило в конкретном проекте, либо — нет. Всё-таки лучше соблюдать единообразие.


    недостаток комментариев в коде по мнению код-ревьюера

    Как правило, это мягкая формулировка "WTF?" по отношению к некоторым участкам кода. Т.е. если это не абстрактное "надо бы побольше комментариев", а с указанием неочевидных мест в коде, то это вполне объективный косяк.

  • Кто вы? Как научились программировать? К чему стремитесь? 20000 ответов
    0

    Заголовок неправильно перевели, вот и возникла путаница… В оригинале "We asked 20,000 people who they are and how they’re learning to code.".
    Т.е. опрос среди тех, кто учится программировать, и, вероятно, хочет стать программистом.

  • Как учить по 100 английских слов в день
    0

    Спасибо за ссылку, интересная статистика.


    И вы предлагаете во избежание одной рутины (лазить в словарь) воспользоваться другой рутиной (обработать весь текст, наделать карточек и заучивать их в течение какого-то промежутка времени)

    Ну, смотрите, Вы написали, что читали "Трое в лодке не считая собаки" адаптированную по методу Франка почти два месяца. При этом это довольно короткая повесть, а метод Франка позволяет читать с весьма приличной скоростью. Из этого я делаю вывод, что Вы пытались какую-то дополнительную работу провести в эти 2 месяца, не предусмотренную самим методом, иначе за пару дней прочитали бы. Т.е. у Вас всё равно был какой-то свой рутинный способ запоминания. Но Вы о нём скромно умолчали даже в своей статье.
    Способ, который я описал, имеет одно основное преимущество, он позволяет меньше отвлекаться при чтении или просмотре фильма, т.к. совсем незнакомых слов у вас уже не будет. Да, останутся идиомы, но это на порядок меньше отвлечений. Тут уже будет как sfumkrrr писал, смысл не ясен -> выясняете в чём дело (изучаете грамматическую конструкцию или идиому). Наверно, тут от характера ещё зависит. Меня лично раздражает, когда надо постоянно отвлекаться на чтение словарных статей.
    А изготовление карточек можно во вполне увлекательный процесс превратить, подключая ассоциативное мышление, определения из толкового словаря и т.д. В принципе, пока Вы делаете карточку Вы уже слово/идиому/правило хорошо запомнили и с примером употребления и с определением и с ассоциациями.
    А метод Франка и метод комментированного чтения — это бесспорно хорошие варианты, но они очевидно на несколько порядков снижают список доступных материалов. Ну а с фильмами и сериалами уже совсем никак не помогут.


    И не все слова вообще требуется переводить, часть угадывается по контексту уже понятого.

    Ну, тут палка о двух концах, с одной стороны в плане художественного восприятия можно и не переводить такие слова (я, например, меньше внимания уделяю словам, которые всего 1 раз в тексте встречаются). А в плане изучения языка, совсем не факт, что вы это слово правильно угадаете, и есть риск неправильный смысл запомнить, если оно часто в тексте встречается.


    P.S.: результат — at least 11,300 English word families!

    Хороший результат, хотя я думал, что у Вас ещё больше будет… возможно Ваш словарный запас просто хорошо коррелирует с книгами, которые Вы читаете.

  • Как учить по 100 английских слов в день
    0

    По-моему Вы крайне невнимательно читали мой комментарий, там нет ни слова про заучивание слов. Про изучение — есть, а вот заучивание и отрыв от контекста — это Ваши фантазии, вызванные непониманием как эффективно использовать карточки.


    заучивание слов по карточкам почти не помогает распознавать их в речи и использовать при письме

    Карточки без озвучки, или без контекста, или с переводом на русский — это неправильно сделанные карточки.


    Не надо много тысяч слов для чтения в оригинале. Не выбирайте британских классиков, читайте Чака Паланика или Дрю Карпишина.

    Хм, ну во-первых с чего вдруг Вы решили указывать что кому читать? А во-вторых, даже в книгах по программированию обычно порядка 2000 уникальных слов. В художественной литературе по определению их больше. И даже для чтения короткого рассказа в оригинале необходимо знать около 5000 слов, естественно они не все в нём встретятся, но без предварительной подготовки Вы не знаете какие именно слова понадобятся. В более крупных литературных формах вполне может встретиться порядка 8-10 тысяч уникальных слов и чтобы такое читать без адаптации и без предварительной подготовки, нужен словарный запас порядка 20 тыс. слов.


    До этого прочитал пару книг неадаптированных, было тяжело из-за необходимости лазить в словарь по N раз на странице.

    Вот от этого этапа и избавляет подготовка по вышеописанному методу. Хорошо читать книги, когда лишь изредка встречаются незнакомые слова и обороты. Но для начинающих — это не вариант. Впрочем, для них есть вариант адаптированной литературы, типа Cambridge English Readers. Но это простые рассказы, а не Х томов Гарри Поттера, о которых шла речь в комментарии, на который я отвечал.


    P.S. Пройдите тест http://my.vocabularysize.com/, если не затруднит.

  • Как учить по 100 английских слов в день
    –1

    Ну-ну, Вы осознаёте сколько тысяч слов уже надо знать, чтобы пытаться что-то художественное читать в оригинале? Есть прекрасные комбинированные варианты… Например, хотите вы прочитать книгу или посмотреть фильм.
    Шаг 1: Берёте текст книги или субтитры к фильму, загружаете их на что-то типа WordsFromText
    Шаг 2: Тратите для первого раза 1-2 часа (потом быстрее), чтобы пробежаться по всем найденным словам и отметить те, которые знаете.
    Шаг 3: Если неизвестных слов осталось меньше 20% от общего кол-ва, то ok, переходите к следующему шагу, иначе выберите себе контент поближе к своему уровню.
    Шаг 4: Делаете карточки для слов, которые вы не знаете, одну обычную и одну с контекстом (т.е. реальное предложение из книги/фильма, но с пропущенным словом)
    Шаг 5: Гоняете эти карточки в Akka пару недель (ну или меньше, если неизвестных слов мало).
    Шаг 6: Читаете книгу, наслаждаясь повествованием, а не зарываясь в словарь по N раз на каждой странице.

  • Как учить по 100 английских слов в день
    +1
    Ну для изучения по «карточкам» вовсе не обязательно тратить время на их изготовление.

    Как раз таки обязательно. Чужие карточки можно использовать для самого нулевого уровня типа Top-100 существительных, для которых есть чёткий визуальный образ. Когда изучение уже на более абстрактный уровень переходит, то самостоятельное изготовление карточек увеличивает эффективность запоминания на порядок.

  • Как соединить два провода?
    0

    хм, 5 бит на 40 человек уже не хватит… как же вы обходили это ограничение?