Так даже если бы компилятор был способен проверить на полноту использования типов.
Мне кажется, вы тут упускаете ещё один возможный исход – значению параметра shape ничего ведь не мешает быть null… или я не прав? В этом случае ни одна проверка на instanceof не вернёт true.
З.ы. в любом случае, спасибо за статью, хорошее изложение.
Спасибо за список, я-то как дурак выяснял все зависимости при помощи depends.exe, при этом определить необходимость platform-плагинов было весьма нетривиально…
Вот ещё беда, у меня icudt49.dll весит ажно 17 мегабайт! Больше, чем Qt5Сore, Qt5Gui и Qt5Widgets вместе взятые! Не знаете, как с этим можно побороться, отключить ICU? А то как-то грустно выходит, что ради маленькой утилитки на 200 Кб тянется 30+ Мб библиотек.
Ну, насчёт for Mac ничего не могу сказать, не являюсь пользователем этой ОС. Потому же не могу сравнить и с SourceTree :) Подозреваю только, что поскольку маковский GitHub вышел раньше виндового, он, должно быть, чуть стабильнее последнего.
Про for Windows согласен, поначалу было весьма сыро. Но вроде постепенно ситуация нормализуется, багфиксы выходят часто. Сейчас вроде перестало уже напрягать багами. Хотя набор функций, конечно, не сильно широк, и иногда приходится опускаться до консоли либо Git GUI. Но мне всё равно нравится, что это приложение стало как бы точкой входа для меня: я открываю его, там все мои текущие репозитории, я могу легко между ними переключаться. То есть ещё и не надо по папкам ходить стало.
Слышал про эту вещь, но как-то недооценивал. Спасибо, что напомнили, надо всё-таки попробовать, выглядит мощно.
Насчёт keygen я не верно выразился, прошу прощения :) Подразумевалось «делать ssh-keygen на каждой машине», и «делать remote add для каждого нового проекта». С новым проектом, добавлю, ещё напрягало то, что нужно создавать репо на гитхабе в браузере, а потом переключаться в консоль и что-то копипастить. То есть не саму команду remote add меня набирать напрягает, а вот этот сложный танец со сменой окон.
Да, у меня тоже складывается ощущение, что мы разговариваем на разных языках. Причина, имхо — сильно разные исходные точки зрения. Я говорю: гитхаб уникален и это здорово. На этом я строю свои доводы. Но вы продолжаете относиться к гитхабу как к «одному из».
То есть нам с вами правильнее было бы полемизировать не в частностях, не в мелочках, а прямо в наших основных положениях. Вы бы обосновали, что гитхаб — это yet another BitBucket, Gitorious, …, и следовательно, то что делают они, должен делать и он. Я бы объяснил, что я не сдвинут на гитхабе, но у меня есть доводы считать GitHub уникальным порталом, причём самым лучшим из аналогов, и отсюда следует то, почему он имеет право быть исключением из правил.
Но мне кажется, эта дискуссия не стоит ни моего, ни вашего времени. Вероятнее всего, мы останемся при своих. Как долго вы пользуетесь гитхабом? У меня есть стойкое ощущение, что в более конструктивном ключе мы могли бы продолжить эту дискуссию, когда вы попользуетесь им подольше. Ну правда, чем он хорош можно понять только на практике, причём лучше, если эта практика будет включать в себя как регулярную совместную разработку, так и разовую контрибуцию в крупные проекты.
При чём здесь получение денег к закрытию исходников?
Я предположил, что это одна из причин с их стороны, почему разрабы не открывают гитхаб: не хотят терять прибыль. Если вы пытаетесь сказать, что они потеряют прибыль незначительно, если сегодня возьмут и откроют гитхаб полностью, то я радикально не согласен. Посмотрите на цены на Enterprise, это наверняка серьёзная статья дохода, а кто станет покупать сервер-сайд гитхаба за $5000/год, если он будет и так доступен?
Но вообще я огорчён, что из моей пламенной речи вы обратили внимание именно на пункт про деньги :( Я неспроста поместил его в конец, то что до этого, я считаю значительно важнее…
P.S. Я почитал статью, и то, что я не полемизирую с её автором, это значит, что я просто не ставил себе этой цели. Я — хотел просто выразить свою, личную точку зрения (я об этом предупредил в начале), основанную на моём опыте использования GitHub почти с его рождения. Он — поднимает правильные мысли, но они выходят за рамки моего обсуждения.
В вашем примере — да. Заменив слово «портал», частными случаями которого являются и хабр, и GitHub, вы сильно ушли от моей изначальной мысли. Операционная система — инструмент. Инструментов чем больше разных, тем лучше. А я своим пламенным постом пытался доказать, что GitHub в большей степени портал, чем инструмент. Поэтому и логика выделенного вами предложения была в том, что то, что мы теряем от закрытости GitHub'а, совершенно незначительно по сравнению с тем, что мы приобретаем от того, что он один. То есть что он является стандартом де-факто. Стандартизация — это иногда хорошо, вот я о чём.
Эта мысль родилась у меня в процессе написания поста, то есть она такая свежая у меня. Если подумать получше, она может оказаться неверной, признаю. Но вроде явных логических огрехов тут нет.
Причём, особенную радость мне здесь доставляет то, что в этом положительном направлении они идут ещё дальше улучшения веб-интерфейсов. А именно, если поставить клиент Github for Windows/Mac, то можно просто забыть про ssh-keygen, про git remote add, итд. Мелочи? Мелочи. Но ведь как напрягало делать это всё на каждой новой машине, для каждого проекта! Я просто жду не дождусь, когда то же появится под Linux.
У меня есть странная, парадоксальная мысль, что частичная (!) закрытость гитхаба идёт на пользу опен сорсу. Рискну высказать.
Смотрите, давайте «приоткрывать» GitHub постепенно. Для начала сделаем его полностью бесплатным: так, что у каждого будет неограниченное количество приватных репозиториев (в данный момент приватные репозитории — это единственное, за что нужно платить). Как вы думаете, это поспособствует тому, что опенсорсных проектов станет больше? Мне кажется, наоборот, поскольку гораздо легче будет спрятать, сокрыть то, что сейчас хостится там открыто.
А если вообще открыть исходники гитхаба, то станет ещё хуже. Во-первых, это продолжение того, что сказано выше: также легче будет НЕ делать свой проект опен-сорсным, его можно будет сделать приватным не только бесплатно, но ещё и разместить у себя на уютном сервачке. Но это всё даже не главное! Что будет дальше? Начнут плодиться клоны, форки. Опен-сорсные проекты станут размазаны не по двум-трём, как сейчас, крупным хостингам репозиториев, а по десяткам (сотням, тысячам?). Сейчас у многих уважающих себя разработчиков есть аккаунт и GitHub, и BitBucket, и не составляет труда при желании законтрибутить в проект, тем более что такие нововведения, как в этом топике, делают это ещё проще. А так что, каждый раз регаться на очередном СуперДуперХаб, чтобы послать патч в полюбившийся проект? Да ну нафиг! Я пофиксю баг и сам буду юзать, а не буду делиться. То есть, добавляется замедление развития проектов. Понимаете, что тут важно: GitHub не просто набор тулзов, не просто веб-интерфейс к Git'у, по задумке это именно портал. Они же очень стараются для того, чтобы он был именно порталом, который объединяет разработчиков и их усилия. Портал в идеале должен быть один, ну, по крайней мере идентичных порталов-конкурентов должно быть чем меньше, тем лучше, иначе хорошего объединения не будет. Вас же не напрягает, что исходники хабра закрыты? Это разве мешает распространению свободных и хороших мыслей, идей, новостей? Лучше будет, если вместо одного хорошего хабра появится двадцать корявых?
Ну и это всё не говоря уже о меркантильной стороне вопроса. Если разработчики GitHub'а перестанут продавать приватные репозитории, а также GitHub Enterprise (который, кстати, поможет вам, если вам так уж сильно, бешено хочется поиметь свой маленький GitHub на своём сервере), то у них не будет денег не только на пиво, но и на дальнейшее развитие проекта. Вы посмотрите на темп развития проекта, почитайте блог. Как это ни печально, такой энтузиазм редко бывает в проектах, за которые люди НЕ получают деньги. В данном случае, я считаю, разработчики GitHub получают свои деньги заслуженно, более того, я с радостью отдаю им свои $7 в месяц за Micro-план. Это меньшее, что я могу сделать в благодарность за один из основных инструментов моей профессиональной деятельности.
Я не претендую на полноту обзора, но нужно признать: не всякому проекту и/или не во всякий момент времени пойдёт на пользу открытость. Гитхабу в его текущей стадии — не пойдёт, он и без неё достаточно активно и успешно развивается. Я думаю, что со временем он будет всё больше и больше открываться, вероятно, по частям. Как рельсы, на которых он написан: ведь рельсы же выросли из BaseCamp'а, который до сих пор закрыт, а вот рельсы процветают в виде одного из самых активных open-source проектов. Думаю, такая же судьба ждёт отдельные части GitHub'а по мере их устаканивания, а чтобы убедиться в том, что они уже сейчас много выкладывают в открытый доступ, достаточно зайти на https://github.com/github, посчитать репозитории и ещё раз подумать, так ли мало делают разработчики GitHub на благо опен сорса.
Спасибо. (Честно не хотел настолько длинно размазывать)
А я просто всегда ставлю пробел после URL'а, причём уже настолько приучил себя, что даже подсознательно это происходит. Конечно, коряво — пробел перед запятой/скобкой/…, но спокойствие нервов (точно интерпретируется правильно) дороже.
Кстати, насчёт на-коленке-парсеров: разумеется, в нормальных соцсетях и скайпах такое редко встречается. Но лично у меня привычку эту выработали ранние Twitter-клиенты, которых я, когда только зарегался в начале 2009-го, менял много в попытках найти хоть какой-то юзабельный. Вот там-то этого наколеночного безобразия было просто навалом.
Мне очень понравилась эта идея, я это прям так себе здорово представил… А потом прошла вот уже почти неделя и пришло в голову продолжение этой мысли. Одно слово:
Картинг.
Ведь правда: настоящие машины дорогие, настоящие машины тяжёлые, настоящие машины опасные (ниже уже ругали за плохую технику безопасности). То ли дело ставить виртурилку на карты!
Тут уже моё воображение понеслось. Договориться с каким-нибудь картинговым прокатом, поставить на несколько машин виртурилки, и это уже аттракцион, за который можно деньги брать! Я бы отдал за возможность разок прокатиться таким образом. Да что там, я экстремал, я бы ещё потом рискнул сесть в качестве пассажира в карт, управляемый другом, для полноты ощущений! Главное, там уже есть трассы, пригодные для настоящих испытаний, возможность погоняться друг за другом. Есть крытые трассы (а то тут сетуют на зиму). Кроме того, есть мнение, что многие пилоты Formula 1 в молодости начинали с картинга, так что это может оказаться очень близко к тому, что icoz назвал Formula Virt2Real :)
Да никто ведь и не спорит, что если напрячься, то можно это решить без calc. Но chainik верно отметил, что все эти подходы можно объединить словом «извращаются». Потому что те свойства, которые применяются, применяются не по тому назначению, для которого они были задуманы. В итоге, такие решения в целом могут быть непонятными, нечитабельными, трудно модифицируемыми. Мне вот тоже плеваться хочется с около-бутстраповского липкого футера.
Главная мысль моего комментария была в том, что calc привносит не усложнение, а упрощение (пусть не всегда необходимое), и резко улучшает понятность стиля. Мне кажется, ваш тезис о том, что и до calc это можно было решить некоторыми неочевидными способами, только подтверждает эту мысль.
Однако же, я буду благодарен, если вы покажете, как вы это решали с помощью border-box. Всегда полезно знать разные подходы, чтобы выбирать объективно.
Разумеется, вы правы :) В мире CSS проценты — тоже длина. Просто от реального мира осталась привычка, что проценты обычно безразмерны, и глаз немного режет именно это…
Нет, не усложнить. Если вы можете написать ширину явным числом — пишите на здоровье. В случае calc речь-то о другом: иногда вы не можете её написать явным числом, и тут-то calc приходит на помощь.
Если у нас элемент, ширина которого задана не в пикселах, а в процентах, то вы не можете явным числом уменьшить эту ширину на 20 пикселов (которые уходят, например, на поля или границы). Возможность вычесть из процентов пикселы — вот та мощь, которой лично мне зачастую очень не хватало! (Хотя физик внутри меня негодует от такого жестокого, наглого несоблюдения размерностей)
Ну, знать это — уже не в моей компетенции :) Я думаю, что ждать (и стремиться) стоит, но если таковой появится, его заслуга будет явно не в том, что он напишет очередной просмотрщик, а в том, что какую-то новую теорию родит. Хотя, конечно, в отличие от учёных века Менделеева, в наш век мощные инструменты тоже играют важную роль на пути к открытию.
Поэтому если у кого-то найдётся желание этим заняться, есть все шансы побороть конкурентов.
Люди, у которых нашлось желание заняться, у нас в стране уже есть — это разработчики Unipro UGENE. Этот опен-сорсный проект (родом, кстати, из Новосибирска) представляет из себя что-то очень похожее на IDE, только для биоинформатики: такой комбайн, объединяющий множество функций и алгоритмов, а также сторонних тулзов в одной среде. То, что он написан на C++/Qt, позволяет некоторые опен-сорсные тулзы даже встраивать на уровне исходного кода (так поступили, например, с samtools).
К сожалению, до того, чтобы побороть всех конкурентов по набору фич, ему, наверное, ещё далеко. Но я имел удовольствие попрактиковаться в этом проекте в магистратуре, поэтому могу немного рассказать о его нутрях. Вот выше сравнили ДНК с базой данных. Разработчики UGENE придерживаются того же мнения, поэтому базу данных и используют для хранения (либо кэширования, если открываешь обычную fasta или bam), что позволяет работать довольно быстро без необходимости держать гигабайты в оперативной памяти. Например, открыть полный геном человека на нетбуке.
Особенно интересным это становится в случае Next Generation Sequencing. Вот автор называет геномный браузер одномерной картой. Но это не всегда так. На выходе секвенаторов типа SOLiD/Illumina получается куча маленьких обрывков, которые потом выравниваются, в результате чего получается двумерная картина: каждый отрезок ДНК покрыт множеством выровненных на него кусочков, в итоге объём таких данных вырастает уже до десятков гигабайт. На самом деле, потом мы смотрим, какие основания чаще всего встречаются на каждой вертикали, и сворачиваем картинку в одномерную (consensus sequence). Но иногда хочется посмотреть и на «сырые» результаты выравнивания, называемые DNA assembly, что можно делать, например в Tablet или IGV. В UGENE также есть свой Assembly Browser, и вот над его ускорением я преимущественно и работал в своё время. Естественно, он тоже использует базу данных, а ещё кэширует рассчитанный coverage, и т. д. UGENE для меня сейчас — это самый интересный проект, над которым мне приходилось трудиться, так что если есть интерес к этой теме, у меня есть что рассказать о нём и вообще об обработке биоинформатических данных с позиции разработчика.
В заключение хотел бы прокомментировать фразу о том, что «идеального браузера геномов не существует». Я не думаю, что он может существовать. Существует слишком много различных задач, связанных с анализом геномной информации, и поэтому существует множество различных браузеров. Представить себе такой, который был бы хорош во всём, сложно. Поэтому разработчик очередного браузера должен понимать, что будет его «киллер-фичей». В Assembly Browser мы делали ставку на скорость за счёт базы данных и многоуровневых кэшей, но зато там пока очень мало функций: нельзя даже несколько треков смотреть одновременно (в других модулях UGENE — можно). К сожалению, я бы не сказал, что эта ставка сыграла. Так что к вашему призыву побороть конкурентов я бы добавил уточнение: хорошенько подумать, в чём конкретно их побеждать, и не распыляться на многое. Если же сил/смелости на поднятие нового проекта не хватает, можно поконтрибутить в какой-нибудь развивающийся, как, например, UGENE. Команда у него хорошая, с ней будет интересно пообщаться.
Мне кажется, вы тут упускаете ещё один возможный исход – значению параметра
shapeничего ведь не мешает бытьnull… или я не прав? В этом случае ни одна проверка наinstanceofне вернётtrue.З.ы. в любом случае, спасибо за статью, хорошее изложение.
Да! Давно мечтал попробовать эффекты общей теории относительности в каком-нибудь симуляторе, но в Universe Sandbox, кажется, пока такого нет :)
Будут ли чёрные дыры и гравитационное линзирование? ^_^
Вот ещё беда, у меня
icudt49.dllвесит ажно 17 мегабайт! Больше, чемQt5Сore, Qt5Gui и Qt5Widgetsвместе взятые! Не знаете, как с этим можно побороться, отключить ICU? А то как-то грустно выходит, что ради маленькой утилитки на 200 Кб тянется 30+ Мб библиотек.Про for Windows согласен, поначалу было весьма сыро. Но вроде постепенно ситуация нормализуется, багфиксы выходят часто. Сейчас вроде перестало уже напрягать багами. Хотя набор функций, конечно, не сильно широк, и иногда приходится опускаться до консоли либо Git GUI. Но мне всё равно нравится, что это приложение стало как бы точкой входа для меня: я открываю его, там все мои текущие репозитории, я могу легко между ними переключаться. То есть ещё и не надо по папкам ходить стало.
Насчёт keygen я не верно выразился, прошу прощения :) Подразумевалось «делать ssh-keygen на каждой машине», и «делать remote add для каждого нового проекта». С новым проектом, добавлю, ещё напрягало то, что нужно создавать репо на гитхабе в браузере, а потом переключаться в консоль и что-то копипастить. То есть не саму команду remote add меня набирать напрягает, а вот этот сложный танец со сменой окон.
То есть нам с вами правильнее было бы полемизировать не в частностях, не в мелочках, а прямо в наших основных положениях. Вы бы обосновали, что гитхаб — это yet another BitBucket, Gitorious, …, и следовательно, то что делают они, должен делать и он. Я бы объяснил, что я не сдвинут на гитхабе, но у меня есть доводы считать GitHub уникальным порталом, причём самым лучшим из аналогов, и отсюда следует то, почему он имеет право быть исключением из правил.
Но мне кажется, эта дискуссия не стоит ни моего, ни вашего времени. Вероятнее всего, мы останемся при своих. Как долго вы пользуетесь гитхабом? У меня есть стойкое ощущение, что в более конструктивном ключе мы могли бы продолжить эту дискуссию, когда вы попользуетесь им подольше. Ну правда, чем он хорош можно понять только на практике, причём лучше, если эта практика будет включать в себя как регулярную совместную разработку, так и разовую контрибуцию в крупные проекты.
Я предположил, что это одна из причин с их стороны, почему разрабы не открывают гитхаб: не хотят терять прибыль. Если вы пытаетесь сказать, что они потеряют прибыль незначительно, если сегодня возьмут и откроют гитхаб полностью, то я радикально не согласен. Посмотрите на цены на Enterprise, это наверняка серьёзная статья дохода, а кто станет покупать сервер-сайд гитхаба за $5000/год, если он будет и так доступен?
Но вообще я огорчён, что из моей пламенной речи вы обратили внимание именно на пункт про деньги :( Я неспроста поместил его в конец, то что до этого, я считаю значительно важнее…
P.S. Я почитал статью, и то, что я не полемизирую с её автором, это значит, что я просто не ставил себе этой цели. Я — хотел просто выразить свою, личную точку зрения (я об этом предупредил в начале), основанную на моём опыте использования GitHub почти с его рождения. Он — поднимает правильные мысли, но они выходят за рамки моего обсуждения.
Эта мысль родилась у меня в процессе написания поста, то есть она такая свежая у меня. Если подумать получше, она может оказаться неверной, признаю. Но вроде явных логических огрехов тут нет.
ssh-keygen, проgit remote add, итд. Мелочи? Мелочи. Но ведь как напрягало делать это всё на каждой новой машине, для каждого проекта! Я просто жду не дождусь, когда то же появится под Linux.Смотрите, давайте «приоткрывать» GitHub постепенно. Для начала сделаем его полностью бесплатным: так, что у каждого будет неограниченное количество приватных репозиториев (в данный момент приватные репозитории — это единственное, за что нужно платить). Как вы думаете, это поспособствует тому, что опенсорсных проектов станет больше? Мне кажется, наоборот, поскольку гораздо легче будет спрятать, сокрыть то, что сейчас хостится там открыто.
А если вообще открыть исходники гитхаба, то станет ещё хуже. Во-первых, это продолжение того, что сказано выше: также легче будет НЕ делать свой проект опен-сорсным, его можно будет сделать приватным не только бесплатно, но ещё и разместить у себя на уютном сервачке. Но это всё даже не главное! Что будет дальше? Начнут плодиться клоны, форки. Опен-сорсные проекты станут размазаны не по двум-трём, как сейчас, крупным хостингам репозиториев, а по десяткам (сотням, тысячам?). Сейчас у многих уважающих себя разработчиков есть аккаунт и GitHub, и BitBucket, и не составляет труда при желании законтрибутить в проект, тем более что такие нововведения, как в этом топике, делают это ещё проще. А так что, каждый раз регаться на очередном СуперДуперХаб, чтобы послать патч в полюбившийся проект? Да ну нафиг! Я пофиксю баг и сам буду юзать, а не буду делиться. То есть, добавляется замедление развития проектов. Понимаете, что тут важно: GitHub не просто набор тулзов, не просто веб-интерфейс к Git'у, по задумке это именно портал. Они же очень стараются для того, чтобы он был именно порталом, который объединяет разработчиков и их усилия. Портал в идеале должен быть один, ну, по крайней мере идентичных порталов-конкурентов должно быть чем меньше, тем лучше, иначе хорошего объединения не будет. Вас же не напрягает, что исходники хабра закрыты? Это разве мешает распространению свободных и хороших мыслей, идей, новостей? Лучше будет, если вместо одного хорошего хабра появится двадцать корявых?
Ну и это всё не говоря уже о меркантильной стороне вопроса. Если разработчики GitHub'а перестанут продавать приватные репозитории, а также GitHub Enterprise (который, кстати, поможет вам, если вам так уж сильно, бешено хочется поиметь свой маленький GitHub на своём сервере), то у них не будет денег не только на пиво, но и на дальнейшее развитие проекта. Вы посмотрите на темп развития проекта, почитайте блог. Как это ни печально, такой энтузиазм редко бывает в проектах, за которые люди НЕ получают деньги. В данном случае, я считаю, разработчики GitHub получают свои деньги заслуженно, более того, я с радостью отдаю им свои $7 в месяц за Micro-план. Это меньшее, что я могу сделать в благодарность за один из основных инструментов моей профессиональной деятельности.
Я не претендую на полноту обзора, но нужно признать: не всякому проекту и/или не во всякий момент времени пойдёт на пользу открытость. Гитхабу в его текущей стадии — не пойдёт, он и без неё достаточно активно и успешно развивается. Я думаю, что со временем он будет всё больше и больше открываться, вероятно, по частям. Как рельсы, на которых он написан: ведь рельсы же выросли из BaseCamp'а, который до сих пор закрыт, а вот рельсы процветают в виде одного из самых активных open-source проектов. Думаю, такая же судьба ждёт отдельные части GitHub'а по мере их устаканивания, а чтобы убедиться в том, что они уже сейчас много выкладывают в открытый доступ, достаточно зайти на https://github.com/github, посчитать репозитории и ещё раз подумать, так ли мало делают разработчики GitHub на благо опен сорса.
Спасибо. (Честно не хотел настолько длинно размазывать)
Кстати, насчёт на-коленке-парсеров: разумеется, в нормальных соцсетях и скайпах такое редко встречается. Но лично у меня привычку эту выработали ранние Twitter-клиенты, которых я, когда только зарегался в начале 2009-го, менял много в попытках найти хоть какой-то юзабельный. Вот там-то этого наколеночного безобразия было просто навалом.
Картинг.
Ведь правда: настоящие машины дорогие, настоящие машины тяжёлые, настоящие машины опасные (ниже уже ругали за плохую технику безопасности). То ли дело ставить виртурилку на карты!
Тут уже моё воображение понеслось. Договориться с каким-нибудь картинговым прокатом, поставить на несколько машин виртурилки, и это уже аттракцион, за который можно деньги брать! Я бы отдал за возможность разок прокатиться таким образом. Да что там, я экстремал, я бы ещё потом рискнул сесть в качестве пассажира в карт, управляемый другом, для полноты ощущений! Главное, там уже есть трассы, пригодные для настоящих испытаний, возможность погоняться друг за другом. Есть крытые трассы (а то тут сетуют на зиму). Кроме того, есть мнение, что многие пилоты Formula 1 в молодости начинали с картинга, так что это может оказаться очень близко к тому, что icoz назвал Formula Virt2Real :)
Или я слишком размечтался?
Главная мысль моего комментария была в том, что calc привносит не усложнение, а упрощение (пусть не всегда необходимое), и резко улучшает понятность стиля. Мне кажется, ваш тезис о том, что и до calc это можно было решить некоторыми неочевидными способами, только подтверждает эту мысль.
Однако же, я буду благодарен, если вы покажете, как вы это решали с помощью border-box. Всегда полезно знать разные подходы, чтобы выбирать объективно.
calcречь-то о другом: иногда вы не можете её написать явным числом, и тут-тоcalcприходит на помощь.Если у нас элемент, ширина которого задана не в пикселах, а в процентах, то вы не можете явным числом уменьшить эту ширину на 20 пикселов (которые уходят, например, на поля или границы). Возможность вычесть из процентов пикселы — вот та мощь, которой лично мне зачастую очень не хватало! (Хотя физик внутри меня негодует от такого жестокого, наглого несоблюдения размерностей)
Люди, у которых нашлось желание заняться, у нас в стране уже есть — это разработчики Unipro UGENE. Этот опен-сорсный проект (родом, кстати, из Новосибирска) представляет из себя что-то очень похожее на IDE, только для биоинформатики: такой комбайн, объединяющий множество функций и алгоритмов, а также сторонних тулзов в одной среде. То, что он написан на C++/Qt, позволяет некоторые опен-сорсные тулзы даже встраивать на уровне исходного кода (так поступили, например, с samtools).
К сожалению, до того, чтобы побороть всех конкурентов по набору фич, ему, наверное, ещё далеко. Но я имел удовольствие попрактиковаться в этом проекте в магистратуре, поэтому могу немного рассказать о его нутрях. Вот выше сравнили ДНК с базой данных. Разработчики UGENE придерживаются того же мнения, поэтому базу данных и используют для хранения (либо кэширования, если открываешь обычную fasta или bam), что позволяет работать довольно быстро без необходимости держать гигабайты в оперативной памяти. Например, открыть полный геном человека на нетбуке.
Особенно интересным это становится в случае Next Generation Sequencing. Вот автор называет геномный браузер одномерной картой. Но это не всегда так. На выходе секвенаторов типа SOLiD/Illumina получается куча маленьких обрывков, которые потом выравниваются, в результате чего получается двумерная картина: каждый отрезок ДНК покрыт множеством выровненных на него кусочков, в итоге объём таких данных вырастает уже до десятков гигабайт. На самом деле, потом мы смотрим, какие основания чаще всего встречаются на каждой вертикали, и сворачиваем картинку в одномерную (consensus sequence). Но иногда хочется посмотреть и на «сырые» результаты выравнивания, называемые DNA assembly, что можно делать, например в Tablet или IGV. В UGENE также есть свой Assembly Browser, и вот над его ускорением я преимущественно и работал в своё время. Естественно, он тоже использует базу данных, а ещё кэширует рассчитанный coverage, и т. д. UGENE для меня сейчас — это самый интересный проект, над которым мне приходилось трудиться, так что если есть интерес к этой теме, у меня есть что рассказать о нём и вообще об обработке биоинформатических данных с позиции разработчика.
В заключение хотел бы прокомментировать фразу о том, что «идеального браузера геномов не существует». Я не думаю, что он может существовать. Существует слишком много различных задач, связанных с анализом геномной информации, и поэтому существует множество различных браузеров. Представить себе такой, который был бы хорош во всём, сложно. Поэтому разработчик очередного браузера должен понимать, что будет его «киллер-фичей». В Assembly Browser мы делали ставку на скорость за счёт базы данных и многоуровневых кэшей, но зато там пока очень мало функций: нельзя даже несколько треков смотреть одновременно (в других модулях UGENE — можно). К сожалению, я бы не сказал, что эта ставка сыграла. Так что к вашему призыву побороть конкурентов я бы добавил уточнение: хорошенько подумать, в чём конкретно их побеждать, и не распыляться на многое. Если же сил/смелости на поднятие нового проекта не хватает, можно поконтрибутить в какой-нибудь развивающийся, как, например, UGENE. Команда у него хорошая, с ней будет интересно пообщаться.