Вопрос от backend программиста. Расскажите, кому кроме программистов\верстальщиков действительно нужна семантика в html и какие будут минусы, если вместо новомодных footer\section везде использовать старый добрый div?
Разработчики на Go мне яро напоминают воинствующих мусульман в мире IT.
Тут дело в том, что Go стал модным и подтянулось много так называемой «школоты» которые кроме Go мало, что видели. И именно такие громче всех кричат, что нет бога кроме Go. Да и особенности рунета вносят свою лепту.
Дело в том, что код Dropbox был написан на python и ужасно тормозил. Они его переписали на Go и стало всё летать. Они писали об этом https://blogs.dropbox.com/tech/2014/07/open-sourcing-our-go-libraries/
1. Да, вьюха не зависит от модели. От того, что можно будет рисовать пачку прямоугольников, а не один, суть не изменится.
2. Соглашусь, что в идеале можно\нужно вынести. На практике, мы можем получить бесконечное дробление.
RectanglePresenter судя по комментарию в коде «Draw the figure on UI» рисует фигуру где то ещё. Он не является фигурой, а лишь отвечает за то, где и как её отрисовать. В память, на экран, куда-то ещё. И не обязательно именно конкретный Rectangle.
Может я не прав, но как я вижу:
* Прямоугольник передаётся в метод, а не конструктор, потому, что через конструктор в дальнейшем будут передаваться зависимости.
* Добавление методов Contains, Intersects и подобных явно противоречит принципу единой ответственности. В привидённом примере Rectangle является ValueObject, и должен описывать только своё поведение. Методы Contains и подобные лучше вынести в нечто под названием CollisionDetector. Но метод Scale вполне может быть у Rectanagle, т.к. только меняет его свойства, но и здесь можно выделить отдельный класс.
Спасибо за разъяснение. Файлы от сотен МБ и несколько ГБ — это лог за один день, при этом ещё не всегда самые подробный. Всё зависит от нагрузки.
Из консоли мне часто не хватает (или я не умею) следующего — искать в диапазоне времени (например от 10 часов до 11) и часто ещё с подзапросом. На больших файлах получается большой оверхед на поиск по всему файлу несколько раз. Наверно тоже однажды соберусь и напишу свой велосипед.
Правильно ли я понял, что slit загружает весь файл в память? У меня типичный размер логов от сотни мегабайт до нескольких гигабайт. При этом часто пользуюсь less на продакшене и хорошо себя чувствую (как и сервер). Но использую только поиск по regexp. Переход в конец файла — достаточно быстрый (не знаю, где вы вычитали, что для это less загружает весь файл), тормозит только подсчёт количества строк который отменяется по ctrl-с.
Для фильтрации мне всегда было удобнее использовать cat | grep или специализированные средства вроде graylog.
Про автора (на его же сайте впрочем): «Ilya Grigorik is a web performance engineer at Google...»
И тогда остаётся вопрос, почему сотрудник гугла пишет книги для школьников.
Да и эмулятор x86 habrahabr.ru/post/198192
Тут дело в том, что Go стал модным и подтянулось много так называемой «школоты» которые кроме Go мало, что видели. И именно такие громче всех кричат, что нет бога кроме Go. Да и особенности рунета вносят свою лепту.
2. Соглашусь, что в идеале можно\нужно вынести. На практике, мы можем получить бесконечное дробление.
* Прямоугольник передаётся в метод, а не конструктор, потому, что через конструктор в дальнейшем будут передаваться зависимости.
* Добавление методов Contains, Intersects и подобных явно противоречит принципу единой ответственности. В привидённом примере Rectangle является ValueObject, и должен описывать только своё поведение. Методы Contains и подобные лучше вынести в нечто под названием CollisionDetector. Но метод Scale вполне может быть у Rectanagle, т.к. только меняет его свойства, но и здесь можно выделить отдельный класс.
Из консоли мне часто не хватает (или я не умею) следующего — искать в диапазоне времени (например от 10 часов до 11) и часто ещё с подзапросом. На больших файлах получается большой оверхед на поиск по всему файлу несколько раз. Наверно тоже однажды соберусь и напишу свой велосипед.
Для фильтрации мне всегда было удобнее использовать cat | grep или специализированные средства вроде graylog.
И тогда остаётся вопрос, почему сотрудник гугла пишет книги для школьников.
БД должна выбираться не под проект, а под задачи. Так или иначе, в одном проекте могут использоваться как реляционные БД, так и так называемые NoSQL.