1. Мы пришли и спросили у продавца: «Сколько стоят вот эти конфеты?» Он нам ответил: «0 руб. — они списаны».
VS
2. Мы пришли и спросили у продавца: «Сколько стоят вот эти конфеты?» Он нам ответил: «Ой, я не знаю — я тут первый день!»
Поэтому «НЕ ЗНАЮ» у нас в итоге не есть «НОЛЬ».
ps: простите за кэпс
pps: упс., опять пример про ноль — в первом варианте было «Как тебя зовут?»
ppppps: Короче это очень тонкое различие, которое не сразу осознаётся. Да и больше оно академично, нежели практично.
ТС, итоговая система черезчур сложна. Может все-таки почитать доки nginx`а? У него ещё модули есть.
А вот если чего-то у него нет, что есть у апача — только в этом случае наверное стоит добавлять апач, как один бэкэндов. Но точно не для того, на что уже есть прекрасный вариант а-ля php-fpm.
ps: А м.б. это ещё за ISA server спрятать? У него вообще по-мойму всё можно сделать :)
> Почему многие студии считают, что прогрессивное улучшение делает разработку слишком долгой
> и слишком дорогой, а поэтому ненужной клиентам?
Даже если мы все квалифицированы, то не факт, что надо делать именно так. Если бизнес-условия позволяют — делаем, иначе нет.
Это банальный элемент качества и не более того. Вот лично мне как разработчику он ОООЧень нравится, но клиенту вполне может быть реально не нужен. Вот прям чесна!
> На сервере волшебным (нет, правда волшебным!) образом
Только если руки не из жопы, т.к. зависимости никто не отменял и в случае чего мы не падаем, но в логи сыпется err: и в итоге у нас конечное состояние не то. Дебажить тоже трудновато, т.к. папет сам решение о порядке запуска принимает и каждый раз всё может быть по-другому, если мы делаем что-то довольно сложное или у нас не всё учтено.
Вполне себе ничего. Я сам веду всё-всё в гугл-календаре — помогает анализировать, куда время девается, зла не помнить и всё хорошее помнить.
Ещё как вариант именно вам можно взять принцип двойной записи из бухучёта.
У каждого ПМа два календаря — серый — ТУДУ и ярко-цветной — ДАН.
Изначально всё все в туду-версии ложат, как что-то сделал — заходишь в задачу и меняешь у нее календарь на ДАН.
На огромном экране в центре комнаты выводится недельный календарь всех-всех (именно ДАН-версии). На том же экране периодически CI может зеленеть или падать. Для скорости можно даже плагинчик накидать для быстрого «переключения» календаря.
Хотя ежу ясно, что маркер он приятнее и быстрее :)
Это напоминает опять холивар на тему абстракция/конкретика.
Продажи и всё такое — не цель, а больше задача. Цель к примеру — получение прибыли. Но всё это с т.з. директора/владельца.
С т.з. продавца цель — продажа, а задачи уже — звонки, общения и проч.
Если кто-то не умеет ставить цели, то не значит, что надо рекомендовать их не ставить. Не ошибается только тот, кто не существует.
Вот только вопрос по производительности/доступности Хетцнера.
Плюс что мы делать в случае отвала Хетцнера? Или это тупо решается одной константой на уровне приложения?
Товарищи, кто выше писал про другие системы и юзеров, ну конечно же разные в разных осях юзеры — это ежу в танке очевидно.
И посмотреть их 5 секундов.
ps: Btw, всех с Новым Годом! :)
Шеф больше программеру понятен и очевиден, а папет типа как огромный конфиг, нежели скрипт.
И да, как уже выше скзали — они оба из одного и того же руби сделаны + кастомизация на нем же возможна не отходя от кассы.
Мне до конкретики в конкретной реализации мало интересно доходить.
Я пытаюсь объяснить что такое NULL вообще, а не только в оракле. Если мы друг-друга не поняли, то и хрен с ним тогда.
Вообще в любой системе хранения данных NULL не должен быть равен пустой строке — это моё личное мнение и не утверждение про DBMS IKS.
Пример:
1. Мы пришли и спросили у продавца: «Сколько стоят вот эти конфеты?» Он нам ответил: «0 руб. — они списаны».
VS
2. Мы пришли и спросили у продавца: «Сколько стоят вот эти конфеты?» Он нам ответил: «Ой, я не знаю — я тут первый день!»
Поэтому «НЕ ЗНАЮ» у нас в итоге не есть «НОЛЬ».
ps: простите за кэпс
pps: упс., опять пример про ноль — в первом варианте было «Как тебя зовут?»
ppppps: Короче это очень тонкое различие, которое не сразу осознаётся. Да и больше оно академично, нежели практично.
Я сказал: «NULL не д.б. FALSE`ом.»
Это не конкретно про оракл/мусклуь/ё-нейм-хиа.
NULL — это неизвестность, а ноль — это конкретное количество.
— Сколько вешать в граммах?
— Да х.з. vs. — Ноль грамм.
Я за то, что FALSE не есть NULL
Просьба вчитаться внимательнее :)
Пример:
Name: Саша
Sex: NULL
Какого пола у нас Саша?
Или другой вариант поля — IsMale
ps: Ежу ясно, что так не делают, но это конно-вакуумно абстракция.
Также NULL не д.б. пустотой — это просто ничто.
NULL — это когда мы не знаем чего-то, а пустая строка — это мы уже знаем, что чего-то нет.
Кароче это всё равно не хорошо так — как-то не по себе что ли.
А вот если чего-то у него нет, что есть у апача — только в этом случае наверное стоит добавлять апач, как один бэкэндов. Но точно не для того, на что уже есть прекрасный вариант а-ля php-fpm.
ps: А м.б. это ещё за ISA server спрятать? У него вообще по-мойму всё можно сделать :)
> и слишком дорогой, а поэтому ненужной клиентам?
Даже если мы все квалифицированы, то не факт, что надо делать именно так. Если бизнес-условия позволяют — делаем, иначе нет.
Это банальный элемент качества и не более того. Вот лично мне как разработчику он ОООЧень нравится, но клиенту вполне может быть реально не нужен. Вот прям чесна!
Ибо мы по разные стороны :)
Подходит для начала или если парк крайне маленький (masterless подход — без мастера). Более правильно делать через клиент/сервер (master).
IDE: Eclipse + Ruby development tools + Gepetto (это то и есть то самое, что надо).
Gepetto update site: download.cloudsmith.com/geppetto/updates
Категория: Gepetto
Имя: Gepetto
> На сервере волшебным (нет, правда волшебным!) образом
Только если руки не из жопы, т.к. зависимости никто не отменял и в случае чего мы не падаем, но в логи сыпется err: и в итоге у нас конечное состояние не то. Дебажить тоже трудновато, т.к. папет сам решение о порядке запуска принимает и каждый раз всё может быть по-другому, если мы делаем что-то довольно сложное или у нас не всё учтено.
Ещё как вариант именно вам можно взять принцип двойной записи из бухучёта.
У каждого ПМа два календаря — серый — ТУДУ и ярко-цветной — ДАН.
Изначально всё все в туду-версии ложат, как что-то сделал — заходишь в задачу и меняешь у нее календарь на ДАН.
На огромном экране в центре комнаты выводится недельный календарь всех-всех (именно ДАН-версии). На том же экране периодически CI может зеленеть или падать. Для скорости можно даже плагинчик накидать для быстрого «переключения» календаря.
Хотя ежу ясно, что маркер он приятнее и быстрее :)
Продажи и всё такое — не цель, а больше задача. Цель к примеру — получение прибыли. Но всё это с т.з. директора/владельца.
С т.з. продавца цель — продажа, а задачи уже — звонки, общения и проч.
Если кто-то не умеет ставить цели, то не значит, что надо рекомендовать их не ставить. Не ошибается только тот, кто не существует.