Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository.
Эрланг работает с «большими числами», разрядность которых ограничена только размером памяти, выделенной для приложения. Да и для С++ такие либы есть для работы с большими числами: BigDigit и Miracle. Мы проверяли на 1000! — работало очень шустро. Как раз эти либы и юзал в свое время, когда занимался пробемами Ферма, Ейлера и прочих криптографов в разрезе эллиптических кривых.
ну раз уж я на столько приблизился к «оперным» разработчикам, то может хотя бы вы узнаете и объясните, почему Опера на реализует «использовать системные настройки прокси»? А то там внятного ответа так и не последовало.
я в поисках гугла ни разу не видел ссылки на rutracker.org (или torrents.ru). Между тем — у них немеренно пользователей. Таким ресурсам индексирования поисковиком, вероятно, не сильно то и нужно. Популярности им прибавляет шумиха вокруг них. Многи про mega узнали после того, как его начали пытаться залочить, потому что это попало в новости, газеты и телик.
лучше бы допилили то, что плохо работало, чем изменять то, что работате отлично.
1. С системной проксей так ничего и не решается 2,5 года (http://my.opera.com/community/forums/topic.dml?id=713762),
2. В гугл-доксах текст нормально так и не копируется (правда, должен признаться, последние полгода я уже перестал юзать гугл-докс в опере, потеряв последнюю надежду на этот фикс. Может и пофиксили уже...)
Как результат — я не могу юзать оперу на работе вообще: у меня настройки прокси берутся из автоматической конфигурации + Charles постоянно меняет их. Из-за этого все браузеры работают нормально, а в опере на каждую закладку приходится вводить логин-пароль на прокси! + нужны на работе гугл-доксы
Эффект общего вагона… Этот приём вызывает у человека ощущение, что большинство членов социальной группы, к которой он себя относит, или хотел бы относить, или мнение которой значимо для него, считают именно так, а не иначе, имеют конкретные ценности, идеи, разделяют одну точку зрения.
Еще слышал «эффект голого короля» по Андерсену («Новое платье короля»).
В холиваре на счет merge vs rebase пытаюсь придерживаться золотой середины. На что надо обратить внимание новичкам (может следует вынести в основную статью):
<b>rebase</b> «поменяет» все коммиты ветки, которую вы ребейзите. Это выльется в то, что вы теперь не сможете сделать push без force! (если вы ранее делали push этого бранча, разумеется)
Чем длинне ваша ветка (т.е., чем больше коммитов вы сделали от «корня», который перемещаете) — тем дольше и сложнее будет rebase, тем больше вероятность конфликтов и вам прийдется править конфликты для каждого конфликтного коммита, коммитить его и продолжать дальше ребейз (в мерже, например, конфликты будут только по сравнению с конечными состояниями файлов)
т.к. rebase делается сразу для пачки коммитов — возможна ситуация, что у вас будут «некомпилируемые коммиты». Т.е., вы наложите изменения файлов, но при этом, возможно, какие-то патчи сделали «нерабочие» коммиты, где неподключена библиотека, переопределена функция и т.п. Это выльется в проблему, когда нужно будет откатиться назад, на «сребейзнутый» коммит и окажется, что этот коммит «невалидный»
Из моей практики и общих рекомендаций:
Если сомневаешься — делай <b>merge</b>. Он всегда обратим, в отличии от rebase. Если нужны изменения из другой ветки — можно мержить другую ветку в свою хоть каждый день. Проблем не будет. Можно делать cherry-pick, если нужен ровно один патч.
Ребейзи только «свои» ветки, т.е., если ветку создал не ты, или с ней работает несколько человек — не ребейзи ее! (но если уж что-то важное — то предупреди всех, что делал ребейз и им нужно будет обновиться с --force)
rebase нестрашен для веток, которые не пушились на сервер. Тогда не будет конфликтов с репозиторием
У вас перемешаются даты коммитов! Будет очень сложно отследить кто и когда сделал реально коммит. По истории будет казаться, что коммит был позже (выше в графе), но может оказаться, что его делали позже
Никогда не делайте ребейз master бранча!. Мастер-бранч как раз попадает по всем вышеперечисленным пунктам-ограничениям!
Вообще, я «осознал» пока что только одно нормальное приктическое применение ребейза на таком примере цикла разработки:
мы выпускаем новый релиз на основе последнего коммита в master. Ставим на него тег (если надо). Все далее master становится «незыблемым» до следующего релиза.
на основе этого тега-коммита мы создаем ветку/ветки для нового релиза и кодим исключительно в этих ветках, не трогая мастер
ВНЕЗАПНО нам срочно нужно пофиксить баг в последнем релизе и выпустить новый! Что делаем? Фиксим баг, коммитим в мастер (если надо — ставим тег), выпускаем новые релиз с фиксом. Но получается, что все наши ветки на следующий релиз не содержат новый фикс из мастера… rebase — Ваш выход! Все ветки для нового релиза ребейзятся на основе последнего коммита в мастере. А так как мы хорошо читали эту статью и делали все, как здесь написано — то наши атомарные коммиты не вызывают больших конфликтов. И в конце мы получаем наши ветки такими, как буд-то они начались с последней версии мастера!
Когда мы готовы делать очередной релиз: мы мержим все ветку в одну, например release100. В этой ветке все проверяем, фиксим конфликты, потом баги. Когда мы уверены, что релиз готов — мержим release100 в master. А так как мы в мастер до этого ничего не коммитили — этот мерж делается как fast-forward. А нам только этого и нужно!
Git сохраняет в commit только изменения над файлами, которые вы проделали в рабочем каталоге. Множество изменений и даёт нам состояние файла(ов) на определённый момент. Сохраняется набор изменений и имена файлов (объектов), которые относятся к этому изменению.
В корне не согласен! Отличие гит и меркуриал от СВН как раз в том, что коммит — это именно снапшоты всех файлов, а не изменений в сравнении с предыдущим. Если файл не менялся — то сохраняется линк на его предыдущую версию. Именно благодаря этому в гите очень быстро реализуются такие возможности, как:
«мгновенный» чекаут любого коммита (версии). Вернуться на один коммит назад стоит столько же, сколько вернуться к самому первому коммиту (за исключением времени на чтение/запись файлов в файловой системе). Это обусловлено именно тем, что самый первый коммит хранит все файлы, как они были закомичены, как и самый последний коммит. В СВН возвраты к версиям должны пройти назад по всем ревизиям и последовательно применить патчи.
«мгновенное» переключение между бранчами. Причины и ограничения — как и в предыдущем примере.
быстрый merge: если у вас 2 ветки и в каждой 100500 коммитов — для гита это то же самое, что смержить в ветки по 1 коммиту. ибо он просто будет брать и «сливать» готовые файлы. В СВН мержин работает совсем иначе. Если я не ошибаюсь, слияние там просто формирует новый патч, а также делает метку, в какую ветку идти при откате назад.
rebase: этого вообще нет в СВН. Здесь уже нужны последовательные патчи ветки, котороую мы ребейзим, а применятся они будут для формирования снапшотов на коммите, на который мы «накатываем»
При этом, т.к. в репозитории все сжимается компрессором — его размер растет слабо, ибо если мы сделали даже миллиард коммитов с малыми изменениями — компрессор сожмет все отлично, т.к. будут повторятся огромные участки кода! Только бинарники здесь «вносят» большие вклады. Но с бинарниками в СВН та же трабла.
А вот когда мы просим сделать diff — тут-то гиту и приходится сравнивать два файла и формировать патч.
Мой друг (со средним зароботком учителя музыкального коледжа) живет в Англии и у него айфон. Я спросил, зачем он себе айфон купил, ведь дороговат, на что он ответил, что на его контракте это ему вышло очень дёшиво, что-то около 30-40 фунтов за телефон и контракт на год.
Тогда я спросил, зачем он сидит на контракте, ведь дороговато, наверно. На что он ответил, что не в состоянии обеспечивать «неконтрактную» мобилу, т.е. она значительно дороже.
Таким образом получается, что купить залоченый телефон на контракте ему было дешевле, чем купить «чистый» телефон без контракта. И так у них живет большая часть страны. Я так понимаю, что огромная «контрактность» и является основным источником доходов мобильных операторов, поэтому их компании стараются делать контракты очень выгодными + «дарить» телефоны, хоть и залоченые, чтобы обеспечить себе оборот.
я попробовал — пока что не получается нормально: то прокрутка прыгает как хочет, то качество не переключишь быстро. Раньше ютуб хоть предлагал попробовать HTML-5 версию, сейчас уже не предлагает сам: по-умолчанию флеш. Хотя нужно признаться, что в социальном сегменте это один из самых значимых «держателей» флеша насегодня.
Если ошибка один раз появилась, то мы просто исправляем функцию, зачем нам писать тест для этой ошибки? Её больше не будет!
Мне кажется, что именно это утверждение неверно. Не забываем, что эту функцию, возможно, в будущей поменяет кто-то другой, а он даже не будет знать про то, что эта ошибка была.
Частично с автором согласен, но с такими ограничениями:
1) толковые коментарии классам/функциям убирают 90% потенциальных ошибок при будущем рефакторинге, особенно если эти комменты обновляются каждый раз при изменении функции, особенно если пишут в этой функции, почему сделано именно так, а не так, как кажется логичнее. Мне кажется, что по соотношению простота, скорость, эффективность и цена, — это самый оптимальный способ!
2) Тесты не очень нужны, если есть нормальная дока, в которой описано что делает каждый класс и функция. К сожалению, очень часто доки либо вообще нет, либо она не обновляется, либо она написана с потолка, либо описывает общие требования, а не реализацию. Поэтому иногда приходиться понимать логику работы функции анализируя ее название/использование/код, а часто все 3 параметра вообще не коррелируют.
В своей практике из-за отсутсвия этих двух «пожеланий» иногда менял функцию (ибо казалось, что она работает неправильно/медленно/криво), а потом приходилось откатывать изменения (слава git revert !), ибо где-то в глубинах процесса/SDK/еще-где-то есть костыль, из-за которого в функции так же был костыль. Если бы хоть один предыдущий программист утрудился написать коммент, почему он здесь вставил его — я бы не наступал на его же грабли. А проявлялись баги потом через несколько дней/недель и было сложно понять, почему и когда это перестало работать (слава git checkout -> git revert )
Вот в этом случае автоматический тест на «эту ошибку» не помешал бы тоже — он бы мне, вероятно, подсказал, что что-то не так стало в функции!
3) на тесты можно забить, если у вас есть большая QA комада с вполне отлаженными и проверенными тест-кейсами на пару часов! Но это только на огромных бизнеспроектах — они готовы платить за живых QA даже дороже, чем за авто-тесты.
Есть еще одна проблема тестов: их мало написать, их еще нужно поддерживать в актуальном состоянии. Т.е., практически каждое измнение функции/класса должно подразумевать хотя бы пересмотр (если не изменение) теста; но, обычно в силу лени, этого почти никто никогда не делает.
Правда, исходя из того, что оказалось в финальном продукте, создавалось впечатление, будто российское подразделение IBM воспользовалось услугами самого дешевого в Москве бюро переводов, а те в свою очередь наняли самых безграмотных переводчиков.
я как -то пытался оценить расход электрокаров и сейчас на энергии 1кВт*ч электрокар проезжает «порядка» 10 км.,
Вы заложили разъездов в ДЕНЬ: (24ч*100кВт/10 ) = 240 кВт * ч => 2 400 км в день)
Что-то не так:
1кВт*ч электрокар проезжает «порядка» 10 км, тогда по моим «10 кВт в сутки» она проедет 100 км в сутки, но не 2400… Так что все-таки 1 порядок, а не 2.
И, мне кажется, неразумно сразу округлять значение до ближайшего разряда. Потому что сделав так 2–3 раза, легко накопить ошибку на порядок
Это если округлять в одну и ту же сторону все величины. Не углубляясь в подробности скажу так: больше никак не получится. Все данные очень приблизительные, и могут отличаться в разы. Как и писалось выше: ошибка будет составлять приблизительно порядок. Это считается нормальным для задач Ферми. Возможно, данный пример не очень удачен для таких задач, ибо разница получилась всего в 2 порядка, из которых один мог оказаться погрешностью. Но ведь и цель статьи, не доказать, а оценить, а потом найти истину где-то посредине.
У Tesla Sportster такое потребление — 135 ватт·час на километр, у Tesla S — что–то типа двухсот.
Емкость 60 кВт-час, Дальность хода (при 88 км/час) 370 км. Отсюда время: 370/88 = 4 часа (я так понимаю, что 88 км/час это оптимальная скорость с очень большим КПД для этой машины, если не максимальным(!), ибо я не думаю что маркетологи допустили рекламу с реальными (читай — заниженными) данными). Значит в час машинка потребляет 60/4 = 15 кВт-час в час. Далее: 15 кВт-час / 1 час = 15 кВт. Эффективная получится действительно около 1,5 кВт.
Вынужден признаться, что этого я не учел… Хотя мозг упорно не хочет принимать то, что потребляемая мощность электромобилей будет в 10 раз меньше при прочих равных.
У кого-нибудь есть аргументы против того, что не будет 10 кратного выиграша у электромобилей? Ибо у меня, пока что, нет…
К тому же мы с транспортом их сравниваем, а атомных, солнечных или гидроавтомобилей пока не изобрели.
Вот как раз я не сравниваю с транспортом. В статье обсуждается не альтернатива топлива, а на сколько сложно текущую потребность, обеспечиваемую ДВС, обеспечить электричеством. Задача не теряет смысла, если бы у нас не было вообще ТЭС, а были бы только ГЭС и АЭС.
Кроме того, я уже написал выше:
КПД электростанций нас вообще мало интересует: мы онцениваем выходную мощность электроэнергии.
На этом я остановлю эту ветку комментов со своей стороны, если не появится других неучтенных факторов, ибо она немного отоходит от основной темы в сторону.
И я не один такой:
bitbucket.org/site/master/issue/516/repo-backed-pastebin-gists-bb-672#comment-3900693
https://groups.google.com/forum/?fromgroups#!topic/bitbucket-users/XMPiYV9y-ZE
но пока шо битбакет молчит уже 3 года…
1. С системной проксей так ничего и не решается 2,5 года (http://my.opera.com/community/forums/topic.dml?id=713762),
2. В гугл-доксах текст нормально так и не копируется (правда, должен признаться, последние полгода я уже перестал юзать гугл-докс в опере, потеряв последнюю надежду на этот фикс. Может и пофиксили уже...)
Как результат — я не могу юзать оперу на работе вообще: у меня настройки прокси берутся из автоматической конфигурации + Charles постоянно меняет их. Из-за этого все браузеры работают нормально, а в опере на каждую закладку приходится вводить логин-пароль на прокси! + нужны на работе гугл-доксы
Еще слышал «эффект голого короля» по Андерсену («Новое платье короля»).
merge vs rebaseпытаюсь придерживаться золотой середины. На что надо обратить внимание новичкам (может следует вынести в основную статью):<b>rebase</b>«поменяет» все коммиты ветки, которую вы ребейзите. Это выльется в то, что вы теперь не сможете сделатьpushбезforce! (если вы ранее делали push этого бранча, разумеется)rebase, тем больше вероятность конфликтов и вам прийдется править конфликты для каждого конфликтного коммита, коммитить его и продолжать дальше ребейз (в мерже, например, конфликты будут только по сравнению с конечными состояниями файлов)rebaseделается сразу для пачки коммитов — возможна ситуация, что у вас будут «некомпилируемые коммиты». Т.е., вы наложите изменения файлов, но при этом, возможно, какие-то патчи сделали «нерабочие» коммиты, где неподключена библиотека, переопределена функция и т.п. Это выльется в проблему, когда нужно будет откатиться назад, на «сребейзнутый» коммит и окажется, что этот коммит «невалидный»Из моей практики и общих рекомендаций:
<b>merge</b>. Он всегда обратим, в отличии от rebase. Если нужны изменения из другой ветки — можно мержить другую ветку в свою хоть каждый день. Проблем не будет. Можно делатьcherry-pick, если нужен ровно один патч.--force)Вообще, я «осознал» пока что только одно нормальное приктическое применение ребейза на таком примере цикла разработки:
rebase— Ваш выход! Все ветки для нового релиза ребейзятся на основе последнего коммита в мастере. А так как мы хорошо читали эту статью и делали все, как здесь написано — то наши атомарные коммиты не вызывают больших конфликтов. И в конце мы получаем наши ветки такими, как буд-то они начались с последней версии мастера!В корне не согласен! Отличие гит и меркуриал от СВН как раз в том, что коммит — это именно снапшоты всех файлов, а не изменений в сравнении с предыдущим. Если файл не менялся — то сохраняется линк на его предыдущую версию. Именно благодаря этому в гите очень быстро реализуются такие возможности, как:
При этом, т.к. в репозитории все сжимается компрессором — его размер растет слабо, ибо если мы сделали даже миллиард коммитов с малыми изменениями — компрессор сожмет все отлично, т.к. будут повторятся огромные участки кода! Только бинарники здесь «вносят» большие вклады. Но с бинарниками в СВН та же трабла.
А вот когда мы просим сделать diff — тут-то гиту и приходится сравнивать два файла и формировать патч.
Прувы:
git-scm.com/book/ru/Введение-Основы-Git
habrahabr.ru/company/badoo/blog/163853/
Тогда я спросил, зачем он сидит на контракте, ведь дороговато, наверно. На что он ответил, что не в состоянии обеспечивать «неконтрактную» мобилу, т.е. она значительно дороже.
Таким образом получается, что купить залоченый телефон на контракте ему было дешевле, чем купить «чистый» телефон без контракта. И так у них живет большая часть страны. Я так понимаю, что огромная «контрактность» и является основным источником доходов мобильных операторов, поэтому их компании стараются делать контракты очень выгодными + «дарить» телефоны, хоть и залоченые, чтобы обеспечить себе оборот.
А вот на чем КО теряется, это: почему же, все-таки, статическая переменная проинициализировалась 2 раза?
согласен, про это забыл. Сути не меняет: если класс не юзается — то статика не будет проинициализирована.
Мне кажется, что именно это утверждение неверно. Не забываем, что эту функцию, возможно, в будущей поменяет кто-то другой, а он даже не будет знать про то, что эта ошибка была.
Частично с автором согласен, но с такими ограничениями:
1) толковые коментарии классам/функциям убирают 90% потенциальных ошибок при будущем рефакторинге, особенно если эти комменты обновляются каждый раз при изменении функции, особенно если пишут в этой функции, почему сделано именно так, а не так, как кажется логичнее. Мне кажется, что по соотношению простота, скорость, эффективность и цена, — это самый оптимальный способ!
2) Тесты не очень нужны, если есть нормальная дока, в которой описано что делает каждый класс и функция. К сожалению, очень часто доки либо вообще нет, либо она не обновляется, либо она написана с потолка, либо описывает общие требования, а не реализацию. Поэтому иногда приходиться понимать логику работы функции анализируя ее название/использование/код, а часто все 3 параметра вообще не коррелируют.
В своей практике из-за отсутсвия этих двух «пожеланий» иногда менял функцию (ибо казалось, что она работает неправильно/медленно/криво), а потом приходилось откатывать изменения (слава
git revert !), ибо где-то в глубинах процесса/SDK/еще-где-то есть костыль, из-за которого в функции так же был костыль. Если бы хоть один предыдущий программист утрудился написать коммент, почему он здесь вставил его — я бы не наступал на его же грабли. А проявлялись баги потом через несколько дней/недель и было сложно понять, почему и когда это перестало работать (славаgit checkout->git revert)Вот в этом случае автоматический тест на «эту ошибку» не помешал бы тоже — он бы мне, вероятно, подсказал, что что-то не так стало в функции!
3) на тесты можно забить, если у вас есть большая QA комада с вполне отлаженными и проверенными тест-кейсами на пару часов! Но это только на огромных бизнеспроектах — они готовы платить за живых QA даже дороже, чем за авто-тесты.
Есть еще одна проблема тестов: их мало написать, их еще нужно поддерживать в актуальном состоянии. Т.е., практически каждое измнение функции/класса должно подразумевать хотя бы пересмотр (если не изменение) теста; но, обычно в силу лени, этого почти никто никогда не делает.
а те, в свою очередь, воспользовались Промтом
умножил на 1/10, как и делал с ДВС. 15 — это полная, но не вся мощность за сутки используется на полную.
Что-то не так:
1кВт*ч электрокар проезжает «порядка» 10 км, тогда по моим «10 кВт в сутки» она проедет 100 км в сутки, но не 2400… Так что все-таки 1 порядок, а не 2.
С этим одним я согласился ниже: habrahabr.ru/post/177621/#comment_6168537
А можно ли как-то использовать сырую нефть в энергетике, не получая при этом промежуточных фракций? Я тоже не знаю.
Это если округлять в одну и ту же сторону все величины. Не углубляясь в подробности скажу так: больше никак не получится. Все данные очень приблизительные, и могут отличаться в разы. Как и писалось выше: ошибка будет составлять приблизительно порядок. Это считается нормальным для задач Ферми. Возможно, данный пример не очень удачен для таких задач, ибо разница получилась всего в 2 порядка, из которых один мог оказаться погрешностью. Но ведь и цель статьи, не доказать, а оценить, а потом найти истину где-то посредине.
Идем отсюда: news.drom.ru/Tesla-Model-S-18452.html
Емкость 60 кВт-час, Дальность хода (при 88 км/час) 370 км. Отсюда время: 370/88 = 4 часа (я так понимаю, что 88 км/час это оптимальная скорость с очень большим КПД для этой машины, если не максимальным(!), ибо я не думаю что маркетологи допустили рекламу с реальными (читай — заниженными) данными). Значит в час машинка потребляет 60/4 = 15 кВт-час в час. Далее: 15 кВт-час / 1 час = 15 кВт. Эффективная получится действительно около 1,5 кВт.
Вынужден признаться, что этого я не учел… Хотя мозг упорно не хочет принимать то, что потребляемая мощность электромобилей будет в 10 раз меньше при прочих равных.
У кого-нибудь есть аргументы против того, что не будет 10 кратного выиграша у электромобилей? Ибо у меня, пока что, нет…
Вот как раз я не сравниваю с транспортом. В статье обсуждается не альтернатива топлива, а на сколько сложно текущую потребность, обеспечиваемую ДВС, обеспечить электричеством. Задача не теряет смысла, если бы у нас не было вообще ТЭС, а были бы только ГЭС и АЭС.
Кроме того, я уже написал выше:
На этом я остановлю эту ветку комментов со своей стороны, если не появится других неучтенных факторов, ибо она немного отоходит от основной темы в сторону.