Ну то есть основным всё-таки является не конкретный инструмент (и может использоваться и один из перечисленных в статье или ещё какой-то), а процесс (когда все подозрительные места кода изолируются, проверяются и исправляются или помечаются)?
И преимуществ вашего инструмента (а не отдельного от него процесса) вы в этой статье не раскрыли?
(прошу не воспринимать как критику инструмента, насколько я могу судить – он хорош, да и ваши разборы ошибок на Хабре очень радуют)
Э… Если команда не исправила ошибку, найденную другим инструментом – почему «регулярное использование PVS-Studio» заставит её исправить? (а не введение правила «исправлять всё, что найдено использующимся инструментом»)
Ужас. На ровном месте создать себе проблемы с переходом через рёбра вашего многогранника? С каким-то сложным и трудноотлаживаемым кодом, когда надо посчитать расстояние между точками на разных гранях?
Меркатор используется потому, что он прост.
Впрочем, что я беспокоюсь? Ваш подход всё равно не примет никто из тех, от кого зависит развитие OSM (для них проблемы очевидны).
ЗЫ: а если вас беспокоит количество знаков для хранения данных
Где сравнение быстродействия и где хоть один пример качества рендеринга выше, чем в float-реализации?
Ну в смысле зачем всё это? Хочется ведь или быстрее сделать (что маловероятно, т.к. на ровном месте получили кучу делений), или качественней.
P.S. Для нормализации — можете не делить на два, а использовать цепные дроби для приближения (см. в википедии подробности). Будет медленнее, чем по степеням двойки работать, но точнее.
Именно на него был такой драйвер? (емнип не во всех наладонниках железо понимало SDHC)
А ещё были SD (не SDHC) карты на 4G. Нестандартные, но работали.
Почти наверняка её и нет на боевых проектах. А для маленького свечного заводика — идея действительно кажется простой и очевидной (другой пример из той же серии – хранение конфигов в системе контроля версий)
Для сопровождения программы код приходится читать, и тем это делать проще, чем больше он похож на естественный язык, — тогда быстрее вникаешь и сосредотачиваешься на главном.
Вам бы попробовать AppleScript – возможно, мнение бы изменилось.
Максимум сходства с естественным языком… И это совсем не радует.
Не ненависть, а всего лишь озвучивание видимых проблем.
Можно сформулировать иначе: право посылать мне что-то сверх plain text нужно ещё заслужить. Люди из моего контактлиста (для почты — проблема, в ней не очень хорошо проверяется отправитель), подтверждённые мной рассылки. AMP от всех прочих (как и html с кучей картинок и разноцветными шрифтами) я предпочту увидеть сразу в папке "спам".
AMP — это возможность задёшево всунуть в письмо кучу свистелок и перделок. Довольно очевидно, для чего они будут использоваться: для рекламы. Итого, ставим фильтр на AMP — не видим рекламы, профит.
(ну, ещё я просто недолюбливаю AMP из-за довольно неудобной реализации в Chrome/Android, ломающей привычное поведение браузера – но это уже предубеждение, не имеющее отношения к e-mail)
P.S. На самом деле меня устраивали старые добрые plain text письма. То, что сверх – попытка привлечь моё внимание, махая пипидастрами. Конечно, я с неодобрением отношусь к людям, которые это делают, и к людям, которые им помогают.
P.P.S. Технические письма от того же гугла или ещё какие с такими возможностями не выглядят проблемой. А вот получать такое от произвольного отправителя я бы не хотел. Вот и говорю: по умолчанию имеет смысл отправлять в спам, принимая лишь от подтверждённых мной отправителей.
А что странного-то? Как к.ф.-м.н – вы как минимум впереди большинства кандидатов по знанию математики (и, как следствие – наверняка и по навыку работы с абстракциями), это важнее знания каких-то программистских технологий (которые всё равно каждые несколько лет меняются). Учиться вы, судя по всему, умеете и любите. Тридцатник — не возраст (разве что кому-то может быть обидно в 30 начинать джуниором, но если вы можете себе это позволить – завидую...).
В общем, все данные для работы, главное найти на неё достаточно времени :-)
Хотя… Есть необычное: мало у кого хватает решимости вот так раз — и уйти в другую профессию, уже добившись успеха в своей. Уважаю.
“вся вселенная в такое-то время” — такого ведь даже в СТО не бывает (в одной системе отсчёта два события произошли одновременно, в другой нет — очень хорошо видно в парадоксе верблюда)?
Впервые (?) экран в качестве динамика? Когда Xiaomi уже третью модель с такой фичей выпускает (Mi Mix 3)?
А если речь именно про динамик-громкоговоритель — то не очень понятно, в чём смысл.
Приемлемая диаграмма направленности для ВЧ — проблема (экран слишком большой и твёрдый, ни маленький твиттер, ни NXT на стекле не получится), приемлемый бас — проблема (внутренний объём недостаточен для ЗЯ или фазоинвертора, так что всё равно получаем акустическое КЗ). Но если они как-то решили эти проблемы — хотелось бы почитать.
Необходимость помнить лишнюю пару десятков слов, которыми не пользуешься (т.к. проще записать 10ⁿ или, для IT, 1e27).
Результат — увидев в статье "34 мимимиграмма" полезешь в справочник смотреть, что такое мимими. Не страшно, но зачем?
Это не совсем то: если вы просто реализуете ГОСТ — у вас тоже будет «несертифицированное средство». Вопрос, по сути, в том, мешает ли лишний слой шифрования пройти сертификацию.
Вы разобрались (если да — то было бы здорово увидеть, где нормативные документы указывают на недопустимость второго слоя, а не на необходимость использования ГОСТ) или это предположение?
Вот об этом я и спрашиваю. Пока из информации — только коммент выше от rsashka, но информация из третьих рук не годится. Вы, я так понял, тоже не выясняли и не разбирались.
Если Вы не поленились разобраться с этими доками — может, скажете, возбраняется ли ими шифровать «в два слоя» — скажем, AES, а поверх ГОСТ (понимаю, что электричества сожрём больше, но если кому надо и требованиям удовлетворить, и не думать, есть ли бэкдор — выглядит выходом)
Лично мне такие не нравятся ни по дизайну, ни по цене ;-).
Ищу что-то на замену умирающим Pebble. Пока наиболее подходящее из того, что вижу — Amazfit Bip, если наконец сделают в прошивке полноценное управление плеером — можно будет брать.
Для меня звучит как "вы должны разобраться в программировании fpga, тогда сможете использовать связку HDL+Python".
Т.е. нет упрощения входа, есть возможность помимо новых инструментов — оставить старый и привычный. Так?
Э… "Чистый python" — в смысле, что исполняется нормальный питоновский код, и не надо въезжать в новые концепции (т.е. это с тем же успехом мог бы быть код на C или ещё каком языке общего назначения), или в смысле, что обошлись инфраструктурой питоновского интерпретатора, чтобы сделать DSL?
Никогда не задумывался над этим огромным полем из граблей, всегда ходил по тропинкам, где их нет :-). Очень интересно было.
Как в последнем примере: я не напишу так, даже если буду точно знать, где какой конструктор сработает. "Пиши код так, будто поддерживать его будет склонный к насилию психопат, знающий, где ты живёшь".
Таким образом, если вы очень хорошо сохранили структуру мозга (память) со времен школы, то весьма вероятно, что вы им и не пользовались весьма активно.
Да ладно. Если вы не пользовались тем, что учили в школе — много ли шансов, что вы это не забудете?
К примеру, французский я не вспомню (совсем). А вот математику — легко. Потому что на школьную математику поверх легли школьные олимпиады, институтская математика, использование её в работе (использовалось, конечно, гораздо меньше, чем знал — но иногда самые неожиданные разделы). Т.е. школьная математика оказалась именно тем, чем должна была быть — базой для последующего.
При чём тут технари? Проблема вообще не в разделении технарь/гуманитарий, а в выбранном пути — где автор максимально долго писал код без обратной связи, выбрав области, где write-only код наиболее распространён.
Охохонюшки…
Не хотел бы я разгребать код за человеком, который _так_ пришёл в программирование. Потому что всё, всё, буквально всё кричит: этот человек не освоил и не освоит правило «пиши код так, будто поддерживать его будет склонный к насилию психопат, который знает, где ты живёшь».
Самое смешное — для полноценного гуманитария освоить это правило должно быть даже проще, чем для технаря: это же человеческие отношения, гуманитарная область.
Как минимум, использование "в отладочных целях" (помнится, на 8080 это было вообще неизбежно, брейкпойнты ставились внедрением в код команды типа RST 3 — по сути, call 18h, кладёт в стек) исключает использование для чего-то ещё.
А на 8086/88 под DOS порчу памяти под стеком использовали защиты софта для обнаружения отладчика.