В Atom эта строка вызывает некоторое визуальное безумие. То есть, в этом вопросе ему доверять (пока?) нельзя.
Раскрывается она, как в браузере (учитывая браузерное происхождение Atom, это было предсказуемо). Toggle invisibles не выдаёт тот факт, что там что-то не то. Но.Нельзя заехать курсором в область, ограниченную RLO и PDF. Ни стрелками, ни мышью. Во всяком случае, так кажется — при проезжании мимо RDO курсор прыгает на длину, которую он огораживает. Но на самом деле, дело обстоит вот как:
В конце строки якобы пустой хвост. Фактически он не пуст, при попытке его стереть вытирается конец строки, начиная от последних кавычек. Шириной он аккурат в 10 символов, сколько между RLO и PDF. То есть, после проезжания через RDO курсор визуально смещается вправо на длину развёрнутого фрагмента, а фактически заезжает внутрь него. Баг. Хоть понятно, откуда растёт.
А теперь весёлая часть. Если включить грамматику Python, баг видоизменяется — смещение от реального положения уменьшается до 4 символов. Тут я перестал понимать что происходит. Пойду оформлять баг-репорт. Спасибо вам за очередное «wat» :)
Автор утверждает, что enum надо использовать для значений, у которых хорошо выражена численная природа. Но позвольте, что тогда не так с обычными числами?
Автор утверждает, что если он надумает дать дамп данных аналитику, то аналитик не поймёт, что там за чиселки встречаются, если нет явного словаря, который только усложнит работу. Это верно. Зато числа компактнее в памяти, быстрее обрабатываются. Выбирайте, что для вас важнее и насколько.
Автор утверждает, что сравнение состояний между собой приводит к странным результатам. Ну, не надо так делать, если это плохо работает. Используйте числа. То, что enum это числа — деталь реализации (см. конец первого абзаца), обязательной чертой перечисляемого типа является только отношение эквивалентности, но не порядка. Просто компьютеры привыкли к числам и могут их обрабатывать быстрее всего.
Не вполне понимаю, как заполнялась колонка «Деплой».
Если это всё генераторы статических сайтов, то собранный каждым из них результат можно при помощи чего угодно загрузить на сервер, отдающий файлы по HTTP.
Способ поддержки FTP для Octopress, по сути является написанием задания для системы сборки (rake), которая дёргает стороннюю программу (lftp) с целью загрузки указанной директории на сервер. И этот способ, по идее, должен работать с чем угодно, его можно адаптировать и на другие системы, в том числе написать аналог на bash.
… т. е. деплой поддерживается во всех случаях на что угодно, куда можно загружать файлы при помощи командной строки. Тот же Nanoblogger можно с минимумом усилий деплоить и с помощью Git, что почему-то в его графе отсутствует. А FTP и rsync таким образом должно поддерживаться вообще всеми перечисленными.
Поправьте меня, если я в чём-то неправ.
А также совершенно не раскрыта тема наличия или отсутствия подсветки синтаксиса. Слишком узкая фича?
Я, кстати, не считаю, что постпроцессоры не нужны. Я просто не вижу, почему они вообще сравниваются с препроцессорами, они технически растут из разных мест.
Препроцессоры добавляют в CSS возможности, которых там нет: переменные, вынос повторяющегося кода, расчёт значений. С ними проще писать сложные стили с внутренними связями.
Постпроцессоры… просто делают уже имеющийся CSS несколько более совместимым с другими браузерами. И облегчают только процесс написания более совместимых стилей.
Но почему то крошечное пересечение их функциональности (вендорные префиксы) уже порождает (потенциально жаркий и) бессмысленный спор о том, что лучше.
«Понятнее, прозрачнее, управляемее» это к тому, что непосредственно из синтаксиса перед препроцессором можно понять, где обработчик что-то сделает, а где оставит как есть. В случае с постпроцессорами это доверяется некоей программе. А стоит ли ей доверять — ещё стоит выяснить.
А «удобнее» — это понятие в основном субъективное.
Мне сама идея кажется странной, ведь HTTP работает поверх TCP. Прокси, очевидно, устанавливает в обе стороны TCP-соединения, где там место для UDP?
Или это риторический вопрос, объясняющий, почему не хочется UDP?
Jekyll берёт удобством использования. У него и документация хорошая, и хостинг для него удобен. А что возможностей настройки не так много — так большинству и этого хватает. Кому не хватает — всегда можно перейти на инструмент посложнее. Формат постов там на вид похож, переход не будет сложным (при переезде с WordPress на Jekyll, например, я страшно ругался).
На DreamSpark есть Kodu Game Lab. Лично мне больше всего напоминает этакий гибрид Spore и Лого. Там же — SmallBasic, но это уже для «тёртых начинающих».
Мобильной версии нет, русский язык в проверенной мной версии не обнаружен и сомневаюсь, что появился.
Многие гитхаб-блоггеры используют Jekyll, а в нём используется Liquid для описания шаблонов страниц. Есть объект-сайт, в нём объекты-посты, объекты-теги… Довольно жирный намёк на ООП.
Действительно, такое решение не мешает игроку перейти на Google Play и поставить ту оценку, которую заслуживает игра.
EA не хочет объективную оценку. EA хочет высокую оценку, и принимает к этому меры. У пользователя срабатывает что-то вроде ощущения «обещания», которое на практике никем не поддерживается — но пользователь-то не в курсе, что он может совершенно без последствий поставить игре столько звёздочек, сколько она заслуживает. Поэтому такие окна на его решение и «мнение» влияют.
С одной стороны — метод однозначно «грязный». С другой — он опирается на незнание пользователей, а в «незнании собственных прав» (хотя не уверен, что кавычки здесь уместны) и принятии на основе этого не вполне правильных решений виноваты… возможно, даже сами пользователи. Они делают оценку в магазине необъективной. Сами. Своими силами и по доброй воле. Так же, как пользователи попадаются на фишинг, не зная, что проверять. Вот только сработавший фишинг для пользователей действительно опасен, с ним борются. Тут же опасности минимум. Ну, или я её не вижу.
Что это означает лично для меня, как пользователя? Я не буду воспринимать статистику отзывов в Google Play сколько-нибудь серьёзно, пока за это никак не наказывают. И, уверен, не только я. Вряд ли в Google Play этому рады, но пока нас мало — это неважно.
Заметьте, что из Java я упомянул только класс для сборки строк (чтобы было понятно, о чём речь), а сам пример совершенно абстрактный.
Я лично не очень рад доверять разницу между сложностью в О(N) и в O(N^2) компилятору без 100%-ной уверенности, что получится более быстрый вариант (а здесь, из синтаксиса, на вид не должен, если понимать операции). Здесь компилятор спасёт, но он (вы и сами отметили) спасёт не везде. Особенно если речь пойдёт о другой реализации компилятора или вообще не о Java.
Это одна из таких «мелочей», которые относятся к «общей грамотности». Библиотеки могут и не спасти.
Многие, скажем, без всякой задней мысли составляют крупную строку, складывая отдельные строчки простым плюсом. Да, в стандартной библиотеке есть под такую задачу класс (в Java это StringBuilder), но если разработчик о нём не знает, его это не спасёт, и тормозить будет. А в обширном мире практического программирования наткнуться на подзадачу склеивания тонны строк недолго, как и на алгоритм с массивами.
1. С главной страницы на них нет ссылок. Случайно заглянувший может решить, что ресурс закрыт. Бывалый пробьётся.
2. Я думаю, они его сменили перед таким шагом. (ого, уже упомянули)
Раскрывается она, как в браузере (учитывая браузерное происхождение Atom, это было предсказуемо). Toggle invisibles не выдаёт тот факт, что там что-то не то. Но. Нельзя заехать курсором в область, ограниченную RLO и PDF. Ни стрелками, ни мышью. Во всяком случае, так кажется — при проезжании мимо RDO курсор прыгает на длину, которую он огораживает. Но на самом деле, дело обстоит вот как:
В конце строки якобы пустой хвост. Фактически он не пуст, при попытке его стереть вытирается конец строки, начиная от последних кавычек. Шириной он аккурат в 10 символов, сколько между RLO и PDF. То есть, после проезжания через RDO курсор визуально смещается вправо на длину развёрнутого фрагмента, а фактически заезжает внутрь него. Баг. Хоть понятно, откуда растёт.
А теперь весёлая часть. Если включить грамматику Python, баг видоизменяется — смещение от реального положения уменьшается до 4 символов. Тут я перестал понимать что происходит. Пойду оформлять баг-репорт. Спасибо вам за очередное «wat» :)
Автор утверждает, что
enumнадо использовать для значений, у которых хорошо выражена численная природа. Но позвольте, что тогда не так с обычными числами?Автор утверждает, что если он надумает дать дамп данных аналитику, то аналитик не поймёт, что там за чиселки встречаются, если нет явного словаря, который только усложнит работу. Это верно. Зато числа компактнее в памяти, быстрее обрабатываются. Выбирайте, что для вас важнее и насколько.
Автор утверждает, что сравнение состояний между собой приводит к странным результатам. Ну, не надо так делать, если это плохо работает. Используйте числа. То, что
enumэто числа — деталь реализации (см. конец первого абзаца), обязательной чертой перечисляемого типа является только отношение эквивалентности, но не порядка. Просто компьютеры привыкли к числам и могут их обрабатывать быстрее всего.Не вполне понимаю, как заполнялась колонка «Деплой».
Если это всё генераторы статических сайтов, то собранный каждым из них результат можно при помощи чего угодно загрузить на сервер, отдающий файлы по HTTP.
Способ поддержки FTP для Octopress, по сути является написанием задания для системы сборки (
rake), которая дёргает стороннюю программу (lftp) с целью загрузки указанной директории на сервер. И этот способ, по идее, должен работать с чем угодно, его можно адаптировать и на другие системы, в том числе написать аналог наbash.… т. е. деплой поддерживается во всех случаях на что угодно, куда можно загружать файлы при помощи командной строки. Тот же Nanoblogger можно с минимумом усилий деплоить и с помощью Git, что почему-то в его графе отсутствует. А FTP и rsync таким образом должно поддерживаться вообще всеми перечисленными.
Поправьте меня, если я в чём-то неправ.
А также совершенно не раскрыта тема наличия или отсутствия подсветки синтаксиса. Слишком узкая фича?
Препроцессоры добавляют в CSS возможности, которых там нет: переменные, вынос повторяющегося кода, расчёт значений. С ними проще писать сложные стили с внутренними связями.
Постпроцессоры… просто делают уже имеющийся CSS несколько более совместимым с другими браузерами. И облегчают только процесс написания более совместимых стилей.
Но почему то крошечное пересечение их функциональности (вендорные префиксы) уже порождает (потенциально жаркий и) бессмысленный спор о том, что лучше.
А «удобнее» — это понятие в основном субъективное.
Или это риторический вопрос, объясняющий, почему не хочется UDP?
До Sass не сталкивался с ними, были сомнения.
post-checkout. По крайней мере, он не висит где-то в фоне.Мобильной версии нет, русский язык в проверенной мной версии не обнаружен и сомневаюсь, что появился.
С одной стороны — метод однозначно «грязный». С другой — он опирается на незнание пользователей, а в «незнании собственных прав» (хотя не уверен, что кавычки здесь уместны) и принятии на основе этого не вполне правильных решений виноваты… возможно, даже сами пользователи. Они делают оценку в магазине необъективной. Сами. Своими силами и по доброй воле. Так же, как пользователи попадаются на фишинг, не зная, что проверять. Вот только сработавший фишинг для пользователей действительно опасен, с ним борются. Тут же опасности минимум. Ну, или я её не вижу.
Что это означает лично для меня, как пользователя? Я не буду воспринимать статистику отзывов в Google Play сколько-нибудь серьёзно, пока за это никак не наказывают. И, уверен, не только я. Вряд ли в Google Play этому рады, но пока нас мало — это неважно.
Я лично не очень рад доверять разницу между сложностью в О(N) и в O(N^2) компилятору без 100%-ной уверенности, что получится более быстрый вариант (а здесь, из синтаксиса, на вид не должен, если понимать операции). Здесь компилятор спасёт, но он (вы и сами отметили) спасёт не везде. Особенно если речь пойдёт о другой реализации компилятора или вообще не о Java.
Многие, скажем, без всякой задней мысли составляют крупную строку, складывая отдельные строчки простым плюсом. Да, в стандартной библиотеке есть под такую задачу класс (в Java это StringBuilder), но если разработчик о нём не знает, его это не спасёт, и тормозить будет. А в обширном мире практического программирования наткнуться на подзадачу склеивания тонны строк недолго, как и на алгоритм с массивами.
2. Я думаю, они его сменили перед таким шагом. (ого, уже упомянули)