Не согласен с «вы не знакомы с фразой это не мое дело» — умение говорить «нет» важное лидерское качество. Неумеющие говорить нет попадают в корпоративные ловушки — их перегружают и они перегорают. Примеров тьма.
Гуглить не проблема. Проблема в том, что часто люди сразу не думая бегут гуглить и находят бяку какую-нибудь и вставляют в код кое-как.
То есть если есть stackoverflow то грех им не пользоваться, но сначала надо подумать и сформулировать, а также определиться что мы ищем и в какую сторону.
То есть решать по одной схеме «гуглить — не гуглить неправильно». Иногда придется прогуглить 3 разные вещи, и из них слепить решение.
Ну у нас максимум два if. Задача Холланда, не моя.
максимум два раза можно узнать результат — это значит пробу сделать.
if (i mod 3 = 0) — опробировали 1 раз
if (i mod 3 = 0 && i mod 5 = 0) — опробировали 1 раз.
Результат первой пробы можно использовать во второй пробе.
Задача давалась Джоном Холландом отцом генетических алгоритмов, в 70-х годах.
Ключевой момент вашего решения — операция s = ""
Обычно схема fizzbuzz идет следующим образом:
1. Напишите fizzbuzz — написал в 3 if.
2. Напишите fizzbuzz в 2 if. Пишут что и вы.
3. Избавьтесь от изменения переменных. Тут продолжите свои размышления.
Если вы считаете, что в условиях 3 задача не решается — докажите что решений нет. Если решается — решите.
Неумеющий программировать — уходит на пункте 1
Умеющий программировать — решает пункт 2
Математик — решает пункт 3.
Правило следующие:
if { block } then { block } else { block}; if {block} then {block} else {block} — два if
if; if — два if
if then else if; if — недопустимо. Три if
промежуточные результаты можно сохранить в неизменяюю переменную.
Нельзя менять переменную, в вашем случае s = "" недопустимо для пункта 3.
можно вычислять любые выражения, битовые сдвиги, числа — все допустимо.
Обрамляющий цикл — классический for или while.
Еще раз условие задачи для тех кто не понял:
есть понятие пробы. Проба позволяет узнать значение.
есть if () — в скобках мы пробируем значение.
нам надо написать программу, которая:
1. если число делится на 3 выводит «fizz»
2. если число делится на 5 выводит «buzz»
3. если число делится на 3 и на 5 выводит «fizzbuzz».
4. если число не делится на 3, на 5, на 3 и на 5 НЕ выводит ни fizz, ни buzz, а выводит само число
Идея fizz buzz — проверить умение логически мыслить и читать тело задачи.
Задача решается в два if. Если число делится на 3 и на 5, значит оно делится и на 15. Написать в два if не так просто, учитывая output. Но надо сделать именно в два if (else стейтмент можно вводить).
Именно так задача давалась в оригинале.
Попробуйте решить строго в два if
У вас ошибка в расчетах. Вот вы пишете:
«Во время пилотного проекта вы обнаруживаете, что шансы не уложиться в срок для каждой из команд – около 20%. А значит шансы, что опоздает хоть кто-нибудь из них – 0.8^3=0.51»
На самом деле — представляем себе что есть не три команды, а 1 команда которая как будто работает последовательно. Делает 3 проекта подряд.
Какие будут исходы? Не будем утруждать себя формулой Бернулли:
1 раз опоздали, 2 раза не опоздали. Причем таких ситуаций аж 3.
2 раза опоздали, 1 раз не опоздали. Таких ситуаций аж 3.
3 раза опоздали. Таких ситуаций 1.
Как я провел этот анализ. Давайте подумаем наоборот. «Хоть кто-нибудь опоздает — это все равно что от 1 отнять вероятность, что никто не опоздает».
0.8 — вероятность что один не опоздает. Значит что все трое не опоздают — 0.8^3 = ваши 0.512. То есть 0.512 — это никто не опоздает. А что хоть кто-нибудь опоздает — это 0.488
Статья очень хорошая. Помните, что теорию вероятностей не так просто опровергнуть как вам кажется. Спасибо, пишите еще.
нет расслабляться вообще никогда нельзя. Просто надо всесторонне образовываться. Ну вот накодите вы кода. И кто этим кодом будет пользоваться? Вы же для кого-то кодите, надо понимать как минимум для кого и почему. Для этого нужна эмпатия и понимание чего он хочет и как он думает. А вы кодить-шкодить.
Надо никогда не расслабляться и всегда думать головой, а кодить или не кодить — это зависит от деятельности. Я вообще могу два часа ходить туда-сюда, в голове вертя систему информационную, потом сесть на стул две строчки кода написать. и вам следует действовать по этому примеру.
Ну вот теперь надеюсь до многих умников дойдет что затраты такие, что бежать в аутсорс со своей «идеей» для мобильного приложения — дело весьма убыточное.
Вам рекомендую послушать песню The Love Of Richard Nixon
Конкретно бизнес-процесс — логистическое view. Пример: покупаем карандаши. Куда отправить заявку, кто ее получит и когда, куда он побежит у кого он купит. Бизнес-процесс? Бизнес-процесс. Лучше чтобы их кто-то инженерил.
Enterprise level — это стратегия (что мы сделали, делаем и куда вообще хотим идти своей долбаной компанией) + структура предприятия.
Business Process Level — уже понятно. Логистические схемы. Что и как покупаем, продаем, сбываем производим. Все цепочки.
Infrastructure Level — маппинг людей, должностей и отделов на бизнес-процессы.
IT Infrastructure Level — информационные системы нужно выделять в отдельное view.
Financial Level — надо добавить. «токовая» модель, куда втекают денежки, куда вытекают. Чтобы мы знали что мы неубыточны своей компанией.
Так, судя по вашему анализу, видно что это все в ужасном состоянии от одной терминологии можно шею свернуть. Так этому учить совершенно нельзя. Напрудили прудов.
Вполне неплохая структурная модель дверей, турникетов и хозяев. Журнал есть, учет есть. Есть что анализировать, например, кто куда ходит или кто приходит и как уходит. Любые терки с безопасностью с переложением ответственности друг на друга и со всем прочим моментально исчезают.
По этой модели уже можно сделать реальную систему. В принципе, хорошая работа, но увы не могу сказать что это крутая структурно-инженерная модель, поскольку предметная область достаточно простая. Однако модель хорошая.
Крайне не рекомендую книгу Фридла для регулярных выражений. Она плохая, плохо написанная и имеет кучу всяких проблем. Такая же плохая как и книга Кнута.
Фактически оба уничтожили или как минимум покоробили свою индустрию — регулярные выражения заработали репутацию чего-то сложного и непонятного потому что Фридл написал ПЛОХУЮ, СЛОЖНУЮ, ОТВРАТИТЕЛЬНУЮ КНИГУ.
Из литературы на рынке мне понравилось:
Python Regular Expressions
Б.Форта Регулярные выражения за 24 часа (аж 2004 года что ли)
Неплохое введение если не ошибаюсь было в книге XSLT Дага Тидвелла
>Нам нужно принять фразу Твена так: «Решайте сложнейшие задачи в первую очередь».
Это просто greedy-приоритизация тасков. Как и всякая эвристика необязательно оптимальна. Иногда стоит попинать вола, то есть попрокрастинировать над сложнейшей задачей, иногда стоит пойти в библиотеку, иногда сначала сделать ресерч, а иногда сразу на нее кидаться. Не могу сказать как лучше.
Я считаю себя достаточно успешным человеком, утро начинаю с выкуривания сигареты.
Совершенно не согласен с тезисом, точнее согласен — но скорее этот тезис иллюстрирует убогость и однобокость мышления работодателя:
>Работодателю интересно, чтобы Вы не росли профессионально, а росли производительно >(больше однотипной ответственности).
Работодателю должно быть интересно, чтобы вы росли профессионально тогда вам можно поручать более сложные и ответственные задачи. Возможно просто ваши с работодателям представления расходятся — например, работодателю желательно чтобы вы углубились в предметную область, а вам в какую-то новую sexy-технологию. В любом случае с работодателем можно и нужно договариваться и разговаривать.
>Работодателю интересно, чтобы Вы углублялись в стек тех технологий, которые использует >он сейчас. Если стек вдруг поменяется, то лучше найти синьора с многолетнем опытом >новой технологии «Х», чем ждать пока Вы переучитесь.
Нет, не лучше. Проект не ограничивается набором какой-то технологии. Проект это и знание людей, и знание каких-то прочих технологий, и знание серверов, и знание баз данных, и знание психологических тонкостей заказчика или заказчиков. Поэтому работодателю интересно вложиться в одного человека на много лет вперед.
Хорошая девелоперская утилита, не уверен насчет Node.js может что-то по структурнее и попровереннее взять? Так в целом незакрытая ниша — сейчас каждый разработчик поднимает какой-нибудь зоопарк (HTTP Server, Database, NoSQL DB, Hadoop, etc).
Почему вы не хотите сыграть на двух уровнях сразу? Или на трех. Вы же уже дерево «предварительное» имеете. Осталось сыграть. Вот и новый алгоритм-болгаритм.
«They made a company based on my research» какое-то. Если я автор уникальной методики, я еще одну методику придумаю. А этот дурень пусть радуется. По опыту, я в свое время работал ассистентом на кафедре, но изобрел пару методик — потом писаются в штаны и прибегают и все равно отстегивают. Главное non-reaction, им страшненько становится.
«Реальное время: нити такого класса всегда вытесняют с процессора нити других классов так быстро, как это возможно»
Дмитрий, я просто предупреждаю что со времени появления защищенного режима процессоров Intel такой класс нитей исчез, условно на этом уровне работает операционная система, daemon триды там глобальные. Но вы что-то свое пилите, отказались из соображений безопасности. Чтобы нить реального времени не сломала что-то (умышленно или случайно). Просто предупреждаю, чтобы вы знали и не наступили на те же грабли, что инженеры Intel. Если вы делаете real time нити это нужно делать осознанно. Извините, пожалуйста, что несколько резкое замечание, но не мог не схватиться за маузер.
То есть если есть stackoverflow то грех им не пользоваться, но сначала надо подумать и сформулировать, а также определиться что мы ищем и в какую сторону.
То есть решать по одной схеме «гуглить — не гуглить неправильно». Иногда придется прогуглить 3 разные вещи, и из них слепить решение.
максимум два раза можно узнать результат — это значит пробу сделать.
if (i mod 3 = 0) — опробировали 1 раз
if (i mod 3 = 0 && i mod 5 = 0) — опробировали 1 раз.
Результат первой пробы можно использовать во второй пробе.
Ключевой момент вашего решения — операция s = ""
Обычно схема fizzbuzz идет следующим образом:
1. Напишите fizzbuzz — написал в 3 if.
2. Напишите fizzbuzz в 2 if. Пишут что и вы.
3. Избавьтесь от изменения переменных. Тут продолжите свои размышления.
Если вы считаете, что в условиях 3 задача не решается — докажите что решений нет. Если решается — решите.
Неумеющий программировать — уходит на пункте 1
Умеющий программировать — решает пункт 2
Математик — решает пункт 3.
Правило следующие:
if { block } then { block } else { block}; if {block} then {block} else {block} — два if
if; if — два if
if then else if; if — недопустимо. Три if
промежуточные результаты можно сохранить в неизменяюю переменную.
Нельзя менять переменную, в вашем случае s = "" недопустимо для пункта 3.
можно вычислять любые выражения, битовые сдвиги, числа — все допустимо.
Обрамляющий цикл — классический for или while.
есть понятие пробы. Проба позволяет узнать значение.
есть if () — в скобках мы пробируем значение.
нам надо написать программу, которая:
1. если число делится на 3 выводит «fizz»
2. если число делится на 5 выводит «buzz»
3. если число делится на 3 и на 5 выводит «fizzbuzz».
4. если число не делится на 3, на 5, на 3 и на 5 НЕ выводит ни fizz, ни buzz, а выводит само число
Example output:
1 2 fizz 4 buzz 6 7… 14 fizzbuzz 16 17
Попробуйте Randl, не знаю С++, что у вас выведется на экране.
Можно написать
for { if else; if else }
можно
for { if; if }
можно
for { if else; if}
и т.п.
оператор print()
Попробуйте честно решить
Задача решается в два if. Если число делится на 3 и на 5, значит оно делится и на 15. Написать в два if не так просто, учитывая output. Но надо сделать именно в два if (else стейтмент можно вводить).
Именно так задача давалась в оригинале.
Попробуйте решить строго в два if
«Во время пилотного проекта вы обнаруживаете, что шансы не уложиться в срок для каждой из команд – около 20%. А значит шансы, что опоздает хоть кто-нибудь из них – 0.8^3=0.51»
На самом деле — представляем себе что есть не три команды, а 1 команда которая как будто работает последовательно. Делает 3 проекта подряд.
Какие будут исходы? Не будем утруждать себя формулой Бернулли:
1 раз опоздали, 2 раза не опоздали. Причем таких ситуаций аж 3.
2 раза опоздали, 1 раз не опоздали. Таких ситуаций аж 3.
3 раза опоздали. Таких ситуаций 1.
0.2 * 0.2 * 0.2 + 3 * 0.2 * 0.8 * 0.8 + 3 * 0.2 * 0.2 * 0.8 = 0.008 + 0.384 + 0.096 = 0.488
Как я провел этот анализ. Давайте подумаем наоборот. «Хоть кто-нибудь опоздает — это все равно что от 1 отнять вероятность, что никто не опоздает».
0.8 — вероятность что один не опоздает. Значит что все трое не опоздают — 0.8^3 = ваши 0.512. То есть 0.512 — это никто не опоздает. А что хоть кто-нибудь опоздает — это 0.488
Статья очень хорошая. Помните, что теорию вероятностей не так просто опровергнуть как вам кажется. Спасибо, пишите еще.
Надо никогда не расслабляться и всегда думать головой, а кодить или не кодить — это зависит от деятельности. Я вообще могу два часа ходить туда-сюда, в голове вертя систему информационную, потом сесть на стул две строчки кода написать. и вам следует действовать по этому примеру.
Вам рекомендую послушать песню The Love Of Richard Nixon
Конкретно бизнес-процесс — логистическое view. Пример: покупаем карандаши. Куда отправить заявку, кто ее получит и когда, куда он побежит у кого он купит. Бизнес-процесс? Бизнес-процесс. Лучше чтобы их кто-то инженерил.
Enterprise level — это стратегия (что мы сделали, делаем и куда вообще хотим идти своей долбаной компанией) + структура предприятия.
Business Process Level — уже понятно. Логистические схемы. Что и как покупаем, продаем, сбываем производим. Все цепочки.
Infrastructure Level — маппинг людей, должностей и отделов на бизнес-процессы.
IT Infrastructure Level — информационные системы нужно выделять в отдельное view.
Financial Level — надо добавить. «токовая» модель, куда втекают денежки, куда вытекают. Чтобы мы знали что мы неубыточны своей компанией.
Так, судя по вашему анализу, видно что это все в ужасном состоянии от одной терминологии можно шею свернуть. Так этому учить совершенно нельзя. Напрудили прудов.
По этой модели уже можно сделать реальную систему. В принципе, хорошая работа, но увы не могу сказать что это крутая структурно-инженерная модель, поскольку предметная область достаточно простая. Однако модель хорошая.
Фактически оба уничтожили или как минимум покоробили свою индустрию — регулярные выражения заработали репутацию чего-то сложного и непонятного потому что Фридл написал ПЛОХУЮ, СЛОЖНУЮ, ОТВРАТИТЕЛЬНУЮ КНИГУ.
Из литературы на рынке мне понравилось:
Python Regular Expressions
Б.Форта Регулярные выражения за 24 часа (аж 2004 года что ли)
Неплохое введение если не ошибаюсь было в книге XSLT Дага Тидвелла
Это просто greedy-приоритизация тасков. Как и всякая эвристика необязательно оптимальна. Иногда стоит попинать вола, то есть попрокрастинировать над сложнейшей задачей, иногда стоит пойти в библиотеку, иногда сначала сделать ресерч, а иногда сразу на нее кидаться. Не могу сказать как лучше.
Я считаю себя достаточно успешным человеком, утро начинаю с выкуривания сигареты.
>Работодателю интересно, чтобы Вы не росли профессионально, а росли производительно >(больше однотипной ответственности).
Работодателю должно быть интересно, чтобы вы росли профессионально тогда вам можно поручать более сложные и ответственные задачи. Возможно просто ваши с работодателям представления расходятся — например, работодателю желательно чтобы вы углубились в предметную область, а вам в какую-то новую sexy-технологию. В любом случае с работодателем можно и нужно договариваться и разговаривать.
>Работодателю интересно, чтобы Вы углублялись в стек тех технологий, которые использует >он сейчас. Если стек вдруг поменяется, то лучше найти синьора с многолетнем опытом >новой технологии «Х», чем ждать пока Вы переучитесь.
Нет, не лучше. Проект не ограничивается набором какой-то технологии. Проект это и знание людей, и знание каких-то прочих технологий, и знание серверов, и знание баз данных, и знание психологических тонкостей заказчика или заказчиков. Поэтому работодателю интересно вложиться в одного человека на много лет вперед.
А еще удовольствие — секс там, конфеток пожрать, и так далее.
Дмитрий, я просто предупреждаю что со времени появления защищенного режима процессоров Intel такой класс нитей исчез, условно на этом уровне работает операционная система, daemon триды там глобальные. Но вы что-то свое пилите, отказались из соображений безопасности. Чтобы нить реального времени не сломала что-то (умышленно или случайно). Просто предупреждаю, чтобы вы знали и не наступили на те же грабли, что инженеры Intel. Если вы делаете real time нити это нужно делать осознанно. Извините, пожалуйста, что несколько резкое замечание, но не мог не схватиться за маузер.