Мне уже не терпится увидеть третий шедевр…
И главное, что пугает — это уже кем-то реализовано на практике.
Основная проблема по статье с часовыми поясами:
UTC — не должен зависеть от часового пояса, локальное время — должно. Смешивая эти два понятия Вы выносите мозги вообще всем.
Проблемы в данном случае:
Манипуляция с тремя таблицами и дополнительными вьюшками… Извините, слегка овер-инжиниринг на пустом месте, для выгрузки данных из базы.
Что-то мне подсказывает, что использовать исключительно цифры в названиях таблиц и полей — не очень-то и здоровая идея, которая безумно усложняет поддержку.
«свой встроенный язык программирования в систему» — учитывая всё прочитанное, извините, очень страшно, но безумно интересно увидеть его описание.
LOG_PACET — граммарнаци негодуют (А гугл транслейт распознаёт это как индонезийский и подсказывает перевод — «слизни»)
Во-первых https://github.com/diogomonica/apachehackdemo/blob/master/setup.sh
Во-вторых, докер-команды, чтобы понять, что у вас вообще имеется на данный момент
docker images -a //all images
docker ps -a // all containers
И наконец, имена для образов и контейнеров докер придумывает сам, если не указано конкретное значение (docker build, -t, --tag value Name and optionally a tag in the 'name:tag')
На практике, в Docker'e можно выделить отдельные Volume для пользовательских данных, для конфигов и для кеша, и при необходимости банально убивать volume с кешем.
А исполняемый контейнер — да, выставить в read-only.
ИМХО: Применяя Закон Парето к Золотому Сечению получается как раз Правило Третей.
Куда проще на глаз отмерить треть, чем 5/8 с какими-то ещё там дробями.
omnisens правильно указал на тот толстый намёк послания, что был заложен ранее.
Даже просто если посмотреть по датам той-же страницы Вики
Парето сформулировал принцип в 1897 году
Кривая Лоренца (графический вариант закона Парето) появилась в 1905 году
Название «Закон Парето» появилось в 1941
Ричард Кох родился в 1950
Простите, после сдачи статистики в институте меня аж всего зачесало, как прочёл эту строку.
Первая мысль была «Коч? Кто это вообще такой?»
Можете не рассказывать даже… Сейчас на мейнфрейме DB2 ворочается с огромной системой, имею наглость наблюдать и даже немного дописывать…
Впрочем, сильного увеличения гемороя я не заметил. Что в лоб, что по лбу, чуть больше писанины — да это от языка зависит, компиляция и dbrm-ы — секундное дело… Прописка туннеля база-программа привычным create procedure. Всё — можно вызывать.
И DB2, Oracle…
Опять же, автора, видимо, не озадачил выбор языка, на котором писать хранимую процедуру, или возможность вынесения вычислений в скомпилированый модуль…
Помимо прочего, меня немножко смутил синтаксис… Мокрое с мягким сравниваем… PSQL(если не ошибся, копируя из поиска) против PureSql
1, 4) Не факт, иногда может хватить и предложения на метод, или отсылки на существующий документ.
2) Это вообще на первое место ставить, а ещё не забыть упомянуть прототипирование :) На самом деле, просто разный уровень макетирования, абстракции (И на всякий случай, я ни разу не говорил, что необходимо опускаться до коментариев вида «скадываем переменную А и пе...»).
3) Сдаюсь безоговорочно, листок+ручка решают, редко пишу без зарисовок.
На самом деле, сейчас спор уже ни о чём :) Банально — у каждого свои привычки.
Самодокументируемый код? Да хоть плюньте в меня, адепты этого красивого мифа, а я лучше перестрахуюсь с риском схватить всего лишь косой взгляд «вот же тупой прогер был, всё закомментил», зато прямо в коде будут подсказки по алгоритмам или принципам, а в системе контроля версий будут все даты, персоны, ссылки на доки и причины изменений.
Как правило для основной массы «произведений», чуть что сложнее X=Y+2 или древнее полугода — начинается территория ужасов. Причём есть даже примеры из весьма солидных контор, когда в энтерпрайз коде, пол года назад сданном в продакшен и не раз уже проданном, замечали явный бред.
Нет, возникло небольшое недопонимание, давайте тогда по шагам.
1) Допустим, алгоритм продумали, не записали, начали сразу кодить, как труЪ герой.
2) В процессе Вас отрывают на неопределённое количество времени. («Слууушай дорогой, а у меня есть новость, ты стал папой! Правда, здорово?» «Да, милая, вот сейчас, через часов 10, допишу код только...»)
3) Возвращаясь к недонаписанному коду, вспоминаете, что это была малознакомая, либо непростая область, например, графику мучали, или нужно было писать нечто согласованное с несколькими большими формулами-законами. Возможно сам алгоритм даже в голове занимал у Вас полотнище размером с футбольное поле, исписанное мелко-мелко да ещё и хлебными крошками.
4) Есть выбор: посмотреть на краткое описание алгоритма в комментариях, либо начинать заново продумывать алгоритм или архитектурные решения.
Ну да, разумеется, можно писать крутую и модную документацию, технические спецификации, но как часто они соответствуют правде?
Первый раз было сказано, что пример сильно утрирован, перед самим примером.
Я то и алгоритм сложить могу, и даже держать его в голове энное время, пока не закодирую, но вот никто не даст гарантии, что в это время на меня не рискнут свалить какую-нибудь рабочую или домашнюю неожиданность, что я сам не отвлекусь, что не придётся реанимировать комп после внезапного скачка напряжения. Ну Вы поняли, да?
Если утрировать, сильно утрировать: «Зачем нам контроль версий? Мы всегда сами помним что и зачем было сделано даже другими людьми в прошлом веке на устаревшей технологии, неужто алгоритм не удержали в голове?». Как-то так…
Автор аж два раза сказал, что так делать именно так не стоит :) Для того и утрируют, чтобы в глаза бросилось.
В целом же, я за подобный подход — перед кодированием описать алгоритм в комментариях очень часто бывает полезным.
Просто при клике на большие красные кнопки «скачать» и «посмотреть» скачивается странный экзешник… А сама кнопка на скачку документа там, куда взгляд обиженного экзешником человека врятли опустится :)
habrahabr.ru/blogs/google/123157
Если этим способом Вас приглашали… Чёрт знает, как оно срабатывает, у меня одного человека в 31 минуту не пустило (со словами «подождите»), а в 36 и 50+ — без проблем люди проскочили внутрь.
И главное, что пугает — это уже кем-то реализовано на практике.
Основная проблема по статье с часовыми поясами:
UTC — не должен зависеть от часового пояса, локальное время — должно. Смешивая эти два понятия Вы выносите мозги вообще всем.
Проблемы в данном случае:
Манипуляция с тремя таблицами и дополнительными вьюшками… Извините, слегка овер-инжиниринг на пустом месте, для выгрузки данных из базы.
Что-то мне подсказывает, что использовать исключительно цифры в названиях таблиц и полей — не очень-то и здоровая идея, которая безумно усложняет поддержку.
«свой встроенный язык программирования в систему» — учитывая всё прочитанное, извините, очень страшно, но безумно интересно увидеть его описание.
LOG_PACET — граммарнаци негодуют (А гугл транслейт распознаёт это как индонезийский и подсказывает перевод — «слизни»)
Во-вторых, докер-команды, чтобы понять, что у вас вообще имеется на данный момент
И наконец, имена для образов и контейнеров докер придумывает сам, если не указано конкретное значение (docker build, -t, --tag value Name and optionally a tag in the 'name:tag')
А исполняемый контейнер — да, выставить в read-only.
Куда проще на глаз отмерить треть, чем 5/8 с какими-то ещё там дробями.
Даже просто если посмотреть по датам той-же страницы Вики
Парето сформулировал принцип в 1897 году
Кривая Лоренца (графический вариант закона Парето) появилась в 1905 году
Название «Закон Парето» появилось в 1941
Ричард Кох родился в 1950
Простите, после сдачи статистики в институте меня аж всего зачесало, как прочёл эту строку.
Первая мысль была «Коч? Кто это вообще такой?»
Не хочу придираться, но…
Я просто оставлю это здесь ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9F%D0%B0%D1%80%D0%B5%D1%82%D0%BE
1024 уровня нажатия и инфракрасные датчики для определения расположения в пространстве.
Впрочем, сильного увеличения гемороя я не заметил. Что в лоб, что по лбу, чуть больше писанины — да это от языка зависит, компиляция и dbrm-ы — секундное дело… Прописка туннеля база-программа привычным create procedure. Всё — можно вызывать.
Опять же, автора, видимо, не озадачил выбор языка, на котором писать хранимую процедуру, или возможность вынесения вычислений в скомпилированый модуль…
Помимо прочего, меня немножко смутил синтаксис… Мокрое с мягким сравниваем… PSQL(если не ошибся, копируя из поиска) против PureSql
2) Это вообще на первое место ставить, а ещё не забыть упомянуть прототипирование :) На самом деле, просто разный уровень макетирования, абстракции (И на всякий случай, я ни разу не говорил, что необходимо опускаться до коментариев вида «скадываем переменную А и пе...»).
3) Сдаюсь безоговорочно, листок+ручка решают, редко пишу без зарисовок.
На самом деле, сейчас спор уже ни о чём :) Банально — у каждого свои привычки.
Самодокументируемый код? Да хоть плюньте в меня, адепты этого красивого мифа, а я лучше перестрахуюсь с риском схватить всего лишь косой взгляд «вот же тупой прогер был, всё закомментил», зато прямо в коде будут подсказки по алгоритмам или принципам, а в системе контроля версий будут все даты, персоны, ссылки на доки и причины изменений.
Как правило для основной массы «произведений», чуть что сложнее X=Y+2 или древнее полугода — начинается территория ужасов. Причём есть даже примеры из весьма солидных контор, когда в энтерпрайз коде, пол года назад сданном в продакшен и не раз уже проданном, замечали явный бред.
1) Допустим, алгоритм продумали, не записали, начали сразу кодить, как труЪ герой.
2) В процессе Вас отрывают на неопределённое количество времени. («Слууушай дорогой, а у меня есть новость, ты стал папой! Правда, здорово?» «Да, милая, вот сейчас, через часов 10, допишу код только...»)
3) Возвращаясь к недонаписанному коду, вспоминаете, что это была малознакомая, либо непростая область, например, графику мучали, или нужно было писать нечто согласованное с несколькими большими формулами-законами. Возможно сам алгоритм даже в голове занимал у Вас полотнище размером с футбольное поле, исписанное мелко-мелко да ещё и хлебными крошками.
4) Есть выбор: посмотреть на краткое описание алгоритма в комментариях, либо начинать заново продумывать алгоритм или архитектурные решения.
Ну да, разумеется, можно писать крутую и модную документацию, технические спецификации, но как часто они соответствуют правде?
Я то и алгоритм сложить могу, и даже держать его в голове энное время, пока не закодирую, но вот никто не даст гарантии, что в это время на меня не рискнут свалить какую-нибудь рабочую или домашнюю неожиданность, что я сам не отвлекусь, что не придётся реанимировать комп после внезапного скачка напряжения. Ну Вы поняли, да?
Если утрировать, сильно утрировать: «Зачем нам контроль версий? Мы всегда сами помним что и зачем было сделано даже другими людьми в прошлом веке на устаревшей технологии, неужто алгоритм не удержали в голове?». Как-то так…
В целом же, я за подобный подход — перед кодированием описать алгоритм в комментариях очень часто бывает полезным.
Если этим способом Вас приглашали… Чёрт знает, как оно срабатывает, у меня одного человека в 31 минуту не пустило (со словами «подождите»), а в 36 и 50+ — без проблем люди проскочили внутрь.
По топику и так скриншоты имеются, а если Вы о самом G+, то обзоров уже тьма тьмущая и инвайты от кого угодно можно получить.