И в итоге это все равно придет к тому, что есть здравый смысл, который говорит «ну да, хорошо структурированный код легче модифицировать», но знаете, что будет ответом на вопрос «что такое хорошо структурированный код»? «Тот, который легче модифицировать».
Разложите по кирпичикам «модификацию кода» — и да, вы получите верный ответ.
Например: чтобы модифицировать код, нужно найти место для внесения изменения, вы согласны? Тот участок кода, который функционально определяет текущее поведение программы, которое перестало соответствовать требованиям. Это одна из подзадач, входящих в задачу модификации.
Давайте посмотрим на этот процесс на примере внесения изменения в вид окна для написания комментария, в котором я сейчас печатаю.
Есть моя кодовая база. Где-то в ней находится код этого окна. Если я нормально назвал файл с ним, то у меня есть Map из названия окна в требованиях, к файлу в котором хранится код окна. Например, в требованиях оно Add Comment, в коде AddCommentWindow Сложность поиска в мапе? O(1), если нет коллизий.
Я был не прав и назвал окно не правильно. Но разложил файлики по папочкам с нормальными именами. Чтобы найти нужный файл — иду по пути /habr/ui/posts/comments/edit. Я шел по дереву, сложность логарифмическая.
Я положил все файлики в одну папку и дал им имена file1, file2… Теперь мне нужно зайти в файл, чтобы понять где нужный мне. Сложность поиска — линейная.
Я запихал все в один файл — сложность как минимум линейна.
Вывод — давай имена файлам такие, чтобы потом найти их при упоминании в требованиях, и на всякий случай организуй нормальную иерархию, чтобы худший случай поиска был O(log(n)).
Итак, хорошо структрированный для поиска по требованиям код, это код в котором:
1) для каждой сущности из требований имеется отображение в виде файла с кодом, описывающим поведение этой сущности.
2) организованный в древовидную структуру каталогов, где каждое название каталога является обобщением какой-либо характеристики сущностей из требований, а название каждого каталога каталогов — обобщает характеристики вложенных элементов.
Сойдет за разрешение циклической зависимости?)
Более того, это работает для FizzBuzzEnterprise. Есть задача, код которой укладывается в 10 строк. Предположим, что вместо того, чтобы писать один файл, мы разнесли эти десять строк по синглтонам фабрик фабрик стратегий, с иньекцией зависимости через кодогенерацию. Что мы получили? Логарифм от огромного дерева, вместо константы для поиска файла и линейного поиска в самом файле.
Я хотел показать, что относительно простыми рассуждениями можно свести задачу к виду, который можно формально описать.
В данном случае — в с помощью вычислительной сложности и структур данных.
И сделать из этого выводы, которые не противоречат здравому смыслу.
Теперь неплохо бы их экспериментально проверить.
Поиск, конечно, простой пример. Но, мне кажется, что сложность остальной части задачи не говорит о принципиальной невозможности применения такого подхода. Могу ошибаться.
Окей, в вашем понимании стоимость модификации в качество не входит. В других дискуссиях этот параметр считали важным, я запомню, что стоит уточнить, говорит ли человек в том числе и о нем, говоря о качестве ПО.
Как я уже заметил, я признаю, что иногда склонен пропустить важные этапы объяснения. Я работаю над этим недостатком, спасибо что указали сейчас на его проявление и уделили время для разбора. Я бы сам не заметил.
Блин, опять пропустил слишком много шагов в обьяснении)
В моем понимании, в качество ПО входит не только отказоустойчивость и скорость работы, но и минимизации стоимости внесения в него изменений. Измеряется в в часах или зелёных президентах, не важно.
В ПО изменения вносятся людьми. Им для этого надо сделать довольно много сложных вещей — например, понять что надо получить в итоге, понять где и как вносить изменения, внести их, проверить и т. д.
Если код плохо структурирован — это отнимет у них больше времени.
Вывод — неплохо бы понять, как структурировать код для оптимизации внесения изменений.
Вы серьезно не поняли, что я хотел сказать, или вам так, потроллить?)
На случай если я непонятно выразился:
Корреляцию между представлением графической/текстовой информации и результатами её обработки в мозге. Например, в разрезе запоминания информации.
Пример попроще? Держите: я буду давать вам для запоминания ряд из 12 рандомных букв, и три слова, суммарно на 12 букв. И да, без всяких фокусов, тройки и монолитные последовательности будут с одинаковой колмогоровской сложностью.
Количество информации в них одинаково. В тройках даже больше, там пробел есть.
Предсказываю, что тройки запомнятся лучше.
Есть корреляция. Ее давно заметили писатели и дизайнеры.
Знаете, ведь если я составлю огромное сложноподчиненное предложение, где буду использовать великое количество витеевато-заковыристых терминов, которое будет как бы растекаться маслом мысли по неокрепшему древу вашего мозга, и проводить огромное количество тропинок, ведущих в никуда ваше затерявшееся в дебрях моего монолога внимание, то, кажется мне, что потеряться может не только внимание, но и вы сами, плутая и нарезая круги, среди деревьев бессмысленных слов, пеньков междометий, странных и не очевидных как пальма метафор.
Вы сразу заметите разницу с чистыми фразами. Из которых выкинули весь мусор. Разбили на понятные, завершенные предложения. Они не отвлекают. Не предлагают лишнего. Даже метафоры в них используются для лучшего понимания. Чистый текст — обращается к вам с честностью джентельмена. Грязный — напоминает цыганку с вокзала.
Вы заметили разницу в восприятии двух абзацев? Она же будет между «чистым» и «грязным» кодом. Разницу можно наблюдать, пусть формулы которая описывает ее пока нет. Но это вопрос работы и времени.
Эксперимент у многих ассоциируется с этапом проверки гипотезы.
Смотрите: Вы собрали данные, загнав статьи в сервисы проверки, и, одновременно посмотрев на их популярность. Это первый этап — сбор информации.
Из этих данных вы вывели непротиворечивое объяснение — статьи непопулярны, потому что их пишут плохо — это ваша гипотеза. И это второй этап, на котором вы и остановились.
А вот если бы вы решили проверить эту гипотезу — например, попробовали на более популярном ресурсе написать несколько статей на попсовые темы, и сохранить в них то же количество ошибок — это был бы эксперимент. Если на популярном ресурсе ни одна такая статья не стала бы популярной — это было бы свидетельство в пользу того, что вы правы и проблема в стиле статей. Ваше предположение прошло бы «проверку на прочность».
Но если бы хоть одна из статей «написанных плохо» выстрелила бы — вам бы пришлось признать, что ваша гипотеза провалилась и искать другое объяснение.
Процесс проверки называют экспериментом. Действия от противного, стремление разрушить гипотезу связано с понятием фальсифицируемости.
Вы может и не претендовали на научность, но действовали вполне себе грамотно, просто остановились на полдороги)
А действительно ли быстрее?
Если не рассматривать вебсервис формата «отдай html страницу», а хоть какую-то бизнес-логику?
Статические проверки типов — отличный пример fail-fast концепции.
Ты захотел вызвать функцию из библиотеки и передал туда то, что нельзя? — Ты узнал об этом как только написал код.
Ты хочешь понять из чего состоит ответ от сервера? Ты полностью видишь его структуру и понимаешь что можно и что нельзя с ним делать.
Возможно я просто не умею писать на динамических ЯП, но у меня ни разу не получалось сделать так, чтобы то, что я пишу — заработало без ошибок. Если это не print(1+10).
Создать маленький скрипт, строк на 20, чтобы нейросеточку обучить или там данные в R обработать и график вывести — это ок. Написать, ну хотя-бы нормальный калькулятор, так чтобы новые функции туда вводить парой строчек кода — уже мучения с отладкой и вопросы небу «Что я сделал не так»?
При этом в статическом ЯП я просто пишу и компилирую. И очень часто все работает как ожидалось. IDE отсекает за меня целый класс ошибок, просто не давая мне их сделать. По моему это прекрасно)
PS
А большая часть ошибок возникает там, где были приняты решения формата: «Нет, мы не будем создавать тип для этого перечисления, мы запихаем сюда Int и будем проверять на этапе исполнения».
Давайте-ка я сразу все тезисы и разобью, вы так удобно их написали.
предпринимательство — способ улучшить своё материальное положение
Или ухудшить в случае если вы ошибетесь.
сейчас предпринимательство в IT с большой степенью вероятности «выстреливает».
Это вы по личному опыту судите? Статистику дайте пожалуйста. Очень уж сомнительное утверждение.
сейчас — время возможностей делать новый бизнес.
нужны именно технические знания для успеха.
А еще связи, подвешенный язык, время и куча прочих факторов, которые мы назовем «удача». Тут недавно была статейка с моделькой распределения благ в зависимости от таланта и случайных факторов. Совершенно внезапно, согласно ей случайность играет большую роль, чем талант.
но люди в IT не ощущают необходимости что-то делать для улучшения своего положения.
мало того, стенка возникает даже когда реальные деньги предлагаешь. Удвоить зарплату итп.
то есть им итак более чем хорошо — повод задуматься о переоценке.
А вы им предложили ровно те-же условия и ЗП в 2 раза больше или все же нет?
У меня вот спокойный проект, кучу времени (рабочего) посвятил саморазвитию, компания стабильна, коллектив меня радует, переработок почти не бывает, только в случае критических ситуаций (завтра клиентов на сервер пускать, а прод лежит после доставки). Переработки по собственной инициативе скорее возбраняются — гонят отдыхать)
Я что-то не уверен, что готов уйти крутиться белкой в колесе стартапа даже за x2.
Время, нервы и хорошие отношения с коллективом дорого стоят, а их не так уж просто найти в компенсационном пакете)
— У меня программа глючит.
— Сейчас погуглим, какие фиксы помогают чаще, и поэкспериментируем.
А вы серьезно думаете что врачи работают иначе?)
У них есть черный ящик, который сбоит, есть набор свидетельств в пользу разных гипотез о причинах сбоев. Исходя из свидетельств одним гипотезам присваивается большая вероятность, чем другим. И да, дальше идем ставить эксперименты — стало легче, значит, наверное помогает. Может помогло вообще не оно, но эту проблему решают на этапе тестов препаратов двойным слепым плацебо-контролируемым, с получением статистически значимых воспроизводимых результатов.
И да, я не отрицаю, что есть побочки, есть индивидуальная переносимость препарата, но если вы ничего не знаете про группу схожих препаратов, стратегия «взять первым наиболее эффективный согласно агрегации по куче исследований» — имеет смысл. Врач как ни странно, тоже не сверхчеловек и посмотрев на вас не предугадает какой препарат из группы вам зайдет, а какой нет.
Описанный вами случай с головной болью — вообще не в ту степь. Боль не усиливалась на холоде? И наоборот, не отпускало ли вас в тепле? Если помогал кофеин, то скорее всего за счет расширения сосудов. Или повышения давления. Возможно имел место спазм сосудов, но за несколько недель вы наверняка попробовали спазмолитики. Короче, это уже история про диагностику, а не выбор наиболее эффективного обезболивающего.
Головная боль — это симптом десятков очень разных заболеваний, поэтому нет и не может быть универсального лекарства. Головную боль могут вызывать очень разные механизмы, поэтому нет и не может быть универсального обезболивающего (в исключениях дубина, гильотина и т.п.).
Вы тут где-то запутались. У головной боли действительно куча причин, но делать вывод что универсального обезболивающего нет — как то странно.
Почитайте механизмы действия ибупрофена, нимесулида, декскетопрофена, кеторолака. Обнаружите некоторое сходство.
Как ни странно, обезболивающее не лечит, а уменьшает боль, и для большинства доступных вам НПВС это происходит схожим образом.
Местная анестезия тоже работает более менее одинаково.
Аналогично, депрессия — это синдром, причины симптомов могут быть очень разные. Лечить депрессию без квалифицированного специалиста по рекомендациям из интернета не стоит даже бесплатно, а тут предлагали заплатить за результаты сбора статистики.
Депрессия может быть самостоятельным заболеванием, связанным с нарушением выработки кого то из троицы Норадреналин, Дофамин, Серотонин и лечится, как ни странно, препаратами которые разными способами повышают количество сих нейромедиаторов, например, угнетением их обратного захвата. Я бы с огромным удовольствием взглянул на статистику, по разного типа АД, и тому насколько они помогают, ибо это позволит хоть как-то понять распределение причин депрессии. Например, что чаще помогает СИОЗС/СИОЗСиД/СИОЗСиН?
PS
А врачи частенько те еще специалисты. Меня вот полторы недели гоняли с больной головой и охренительно опухшим лимфоузлом с одной стороны. Пока я сам не залез, и не прочитал что это может быть зуб мудрости. Голова прошла сразу после удаления единственного не вылезшего. Меня до этого наблюдало 6 врачей: лор, 2 терапевта, невролог, терапевт-стоматолог и хирург из омс-ной стоматологии — ни один из них не предположил что проблема в зубе мудрости.
Короче, врачи иногда тоже такая себе экспертная система. Хорошо знать хорошего специалиста, но с этим есть проблемы)
Вы возможно неправильно поняли, не пытался вас оскорбить, или как-то передернуть.
Просто поделился наблюдением, что логическая цепочка «вегетаринец/лесбиянка/феменистка -> фанатичен» не верна. Судя по моей (небольшой и нифига не репрезентативной) выборке, фанатики распределены среди групп людей в более-менее одинаковой пропорции. И именно на фанатизм и стоит обратить внимание, не важно является ли он социально приемлемым или нет.
В 7-9 лет… Не берусь судить, дети разные. Знаю таких, кто осилил бы. Да и начальные главы «лекций» и «вы конечно шутите», по моей памяти очень просты. Но, думаю, есть и специальная детская литература. Может, «Незнайка»?) Я читал только часть «на луне», но если остальные того же формата, должно подойти. Можно поискать еще что-то.
И всегда есть общение. Мои родители интересовались моим мнением, развернуто объясняли если я в чем-то не прав и старались не давить авторитетом в формате «ты маленький, а мы взрослые и знаем как лучше». Иногда, бывало и такое, но никто не совершенен.
Интересная у вас выборка, если она мотивирует вас защищать свою жизнь)
Моя небольшая, человек 5 вегетарианцев, несколько человек разделяющих феменестичные взгляды, ну и ещё человек 6 с нетрадиционными предпочтениями в сексе.
Никто из них не пытался насильно кормить меня фалафелями, не оскорблял за половую принадлежность и не тащил в постель. Так что ни желания, ни потребности жизнь защищать — не возникало.
Иногда о проблемах рассказывали, дескать рацион вегетарианцу составить трудно, или вот с парнем за ручку другому парню не походить — агрессивно настроенные личности могут наехать и дойти до рукоприкладства.
В общем, люди как люди, ничего необычного.
А отдельную выборку составляют, эм… Идиоты. В плохом смысле, а не клиническом. И такие были и среди "мужчина, белый, не вегетарианец, натурал" и среди "притесненных" всех мастей. И вот от кого хочется защищаться — так это от них. Если человек считает что правильно применять насилие к людям просто потому что они относятся к определённой группе, не разделяющей его взгляды — это, кхм, немного пугает. Оправдания у таких обычно разные: мой народ/группу притесняли, теперь я притесню их. Или "мне нужно защитить детей от их пагубного влияния". Или "они болеют за синих, но зелёные лучше!". Столько странных оправданий для несовершенства своих мыслей. Если вы причесали какую-то группу под одну гребёнку, если повелись на стереотип, если приняли мысль толпы, неподумав самостоятельно хотя-бы минуту — вы проиграли. Вы предали свою способность мыслить, а не подчиняться стадному инстинкту, предали то, что делало вас человеком.
Так что лучше дайте своим детям почитать Фейнмана. Пусть смотрят на мир сквозь очки здорового скептицизма и учатся думать своей головой.
Почему вы считаете, что непонимание заказчиком того, как работает конкретно «что-то», говорит о том, что с ним невозможно работать?
У нас на проекте есть аналитик. Он не знает, как внутри работает андроид. Он умеет формулировать задачи достаточно подробно, чтобы я это реализовал. Обычно, то что я реализовал сходится с тем, что представлял аналитик.
Я не вижу зависимости между «Не умеет в программирование» и «Умеет писать требования».
Или вы сделали какой-то другой вывод, а я вас не так понял?
Вообще я не ожидал, что именно первая часть вызовет интерес, и собирался дальше писать про быструю фильтрацию для обеих сторон и текущую ситуацию с оценкой кандидатов.
Я смотрел на ситуацию со стороны «мне нужен сотрудник», а не «у меня огромный штат и мне нужно обеспечивать прибыль компании». Я работаю в небольшом отделе (15 человек или около того), с большими потерями на начальное обучение из-за того, что у нас много своих велосипедов. И когда в кандидата надо вложиться для получения результата это существенно меняет ситуацию. Совсем не хочется, чтобы человек ушел потому что ему не понравились печеньки)
Я совсем не подумал о том, что большинство участников рынка находятся в другой ситуации, у меня тут слепая область. Хотя, из стратегий подбора персонала тем же яндексом и гуглом можно было сделать выводы. В общем — ошибся, бывает)
Буду корректировать модели, соберу информацию и напишу отдельную статью. Думаю, стоит кластеризовать компании. Для мелочи, средних и бегемотов стратегии явно будут разными. И кандидат должен это учитывать.
Согласен, у меня идеализированный случай, где цель компании — эффективный сотрудник на долгий период, а сотрудник ведет себя рационально и, заметив попытки себя обмануть, принимает решение начать поиск новой работы.
Но, даже в таких условиях, ваше замечание про стратегию «быть честным» — отлично работает. Я не подумал о том, что экономия на сотруднике обманом или завышение сотрудником «стоимости себя» можно рассматривать как увеличение выигрыша одной стороны и проигрыш другой. Поскольку мы считаем, что обманутая сторона проиграет независимо от своей стратегии у нас получается ваша матрица игры.
Это работает даже если мы введем штраф с обманутого игрока и выйдем из бинарного случая проиграл/не проиграл. Штраф ведь останется один и тот же для каждой стратегии другого игрока. Например, кандидат сильно завышает цену, а компания недоговаривает об условиях. Предположим, что со стороны компании нанять сотрудника обманув, приведет к выигрышу +0.25 и такому же штрафу сотрудника, а сотрудник выиграет 0.5, если его возьмут по завышенной цене.
(0.5/0.5)(1:0)
(0.25/0.75)(0.25/0.25)
Если оно не поддерживается и там нет особых секретов, может исходники открыть? Думаю тут найдутся добровольцы, которые с радостью будут его допиливать.
Есть вопрос с выкладыванием в сторы, но можно решать проблемы по мере поступления, а Android может и без этого обойтись.
Мне было легче воспринимать все это диаграммной, с частичным пересечением областей «оффер» и «не звонят»:
Картика
Желтое — не звонят. — 0.9 круга.
Зеленое — оффер. — 0.2 круга.
Зелено-желтое — оффер и не звонят. Отношение зеленое/зелено-желтое — 0.4.
Мне нужно узнать вероятность, что я нахожусь в пересечении, зная что я уже в желтой области, и зная, какая часть зеленой области пересекается с желтой. Умножаем 0.2 (зелененькое)*0.4 (отношение зеленого и зелено-желтого) — узнаем какой кусочек всего круга — зелено-желтый. Теперь надо узнать какой кусочек желтой области — зелено-желтый. Зная, что желтая область — 0.9 от всего кружка получаем соотношение 0.2*0.4/0.9. Вот и вся теорема.
Разложите по кирпичикам «модификацию кода» — и да, вы получите верный ответ.
Например: чтобы модифицировать код, нужно найти место для внесения изменения, вы согласны? Тот участок кода, который функционально определяет текущее поведение программы, которое перестало соответствовать требованиям. Это одна из подзадач, входящих в задачу модификации.
Давайте посмотрим на этот процесс на примере внесения изменения в вид окна для написания комментария, в котором я сейчас печатаю.
Есть моя кодовая база. Где-то в ней находится код этого окна. Если я нормально назвал файл с ним, то у меня есть Map из названия окна в требованиях, к файлу в котором хранится код окна. Например, в требованиях оно Add Comment, в коде AddCommentWindow Сложность поиска в мапе? O(1), если нет коллизий.
Я был не прав и назвал окно не правильно. Но разложил файлики по папочкам с нормальными именами. Чтобы найти нужный файл — иду по пути /habr/ui/posts/comments/edit. Я шел по дереву, сложность логарифмическая.
Я положил все файлики в одну папку и дал им имена file1, file2… Теперь мне нужно зайти в файл, чтобы понять где нужный мне. Сложность поиска — линейная.
Я запихал все в один файл — сложность как минимум линейна.
Вывод — давай имена файлам такие, чтобы потом найти их при упоминании в требованиях, и на всякий случай организуй нормальную иерархию, чтобы худший случай поиска был O(log(n)).
Итак, хорошо структрированный для поиска по требованиям код, это код в котором:
1) для каждой сущности из требований имеется отображение в виде файла с кодом, описывающим поведение этой сущности.
2) организованный в древовидную структуру каталогов, где каждое название каталога является обобщением какой-либо характеристики сущностей из требований, а название каждого каталога каталогов — обобщает характеристики вложенных элементов.
Сойдет за разрешение циклической зависимости?)
Более того, это работает для FizzBuzzEnterprise. Есть задача, код которой укладывается в 10 строк. Предположим, что вместо того, чтобы писать один файл, мы разнесли эти десять строк по синглтонам фабрик фабрик стратегий, с иньекцией зависимости через кодогенерацию. Что мы получили? Логарифм от огромного дерева, вместо константы для поиска файла и линейного поиска в самом файле.
Я хотел показать, что относительно простыми рассуждениями можно свести задачу к виду, который можно формально описать.
В данном случае — в с помощью вычислительной сложности и структур данных.
И сделать из этого выводы, которые не противоречат здравому смыслу.
Теперь неплохо бы их экспериментально проверить.
Поиск, конечно, простой пример. Но, мне кажется, что сложность остальной части задачи не говорит о принципиальной невозможности применения такого подхода. Могу ошибаться.
Окей, в вашем понимании стоимость модификации в качество не входит. В других дискуссиях этот параметр считали важным, я запомню, что стоит уточнить, говорит ли человек в том числе и о нем, говоря о качестве ПО.
Как я уже заметил, я признаю, что иногда склонен пропустить важные этапы объяснения. Я работаю над этим недостатком, спасибо что указали сейчас на его проявление и уделили время для разбора. Я бы сам не заметил.
Блин, опять пропустил слишком много шагов в обьяснении)
В моем понимании, в качество ПО входит не только отказоустойчивость и скорость работы, но и минимизации стоимости внесения в него изменений. Измеряется в в часах или зелёных президентах, не важно.
В ПО изменения вносятся людьми. Им для этого надо сделать довольно много сложных вещей — например, понять что надо получить в итоге, понять где и как вносить изменения, внести их, проверить и т. д.
Если код плохо структурирован — это отнимет у них больше времени.
Вывод — неплохо бы понять, как структурировать код для оптимизации внесения изменений.
Где я ошибаюсь, или где вы меня не поняли?)
На случай если я непонятно выразился:
Корреляцию между представлением графической/текстовой информации и результатами её обработки в мозге. Например, в разрезе запоминания информации.
Пример попроще? Держите: я буду давать вам для запоминания ряд из 12 рандомных букв, и три слова, суммарно на 12 букв. И да, без всяких фокусов, тройки и монолитные последовательности будут с одинаковой колмогоровской сложностью.
Количество информации в них одинаково. В тройках даже больше, там пробел есть.
Предсказываю, что тройки запомнятся лучше.
Знаете, ведь если я составлю огромное сложноподчиненное предложение, где буду использовать великое количество витеевато-заковыристых терминов, которое будет как бы растекаться маслом мысли по неокрепшему древу вашего мозга, и проводить огромное количество тропинок, ведущих в никуда ваше затерявшееся в дебрях моего монолога внимание, то, кажется мне, что потеряться может не только внимание, но и вы сами, плутая и нарезая круги, среди деревьев бессмысленных слов, пеньков междометий, странных и не очевидных как пальма метафор.
Вы сразу заметите разницу с чистыми фразами. Из которых выкинули весь мусор. Разбили на понятные, завершенные предложения. Они не отвлекают. Не предлагают лишнего. Даже метафоры в них используются для лучшего понимания. Чистый текст — обращается к вам с честностью джентельмена. Грязный — напоминает цыганку с вокзала.
Вы заметили разницу в восприятии двух абзацев? Она же будет между «чистым» и «грязным» кодом. Разницу можно наблюдать, пусть формулы которая описывает ее пока нет. Но это вопрос работы и времени.
Смотрите: Вы собрали данные, загнав статьи в сервисы проверки, и, одновременно посмотрев на их популярность. Это первый этап — сбор информации.
Из этих данных вы вывели непротиворечивое объяснение — статьи непопулярны, потому что их пишут плохо — это ваша гипотеза. И это второй этап, на котором вы и остановились.
А вот если бы вы решили проверить эту гипотезу — например, попробовали на более популярном ресурсе написать несколько статей на попсовые темы, и сохранить в них то же количество ошибок — это был бы эксперимент. Если на популярном ресурсе ни одна такая статья не стала бы популярной — это было бы свидетельство в пользу того, что вы правы и проблема в стиле статей. Ваше предположение прошло бы «проверку на прочность».
Но если бы хоть одна из статей «написанных плохо» выстрелила бы — вам бы пришлось признать, что ваша гипотеза провалилась и искать другое объяснение.
Процесс проверки называют экспериментом. Действия от противного, стремление разрушить гипотезу связано с понятием фальсифицируемости.
Вы может и не претендовали на научность, но действовали вполне себе грамотно, просто остановились на полдороги)
Если не рассматривать вебсервис формата «отдай html страницу», а хоть какую-то бизнес-логику?
Статические проверки типов — отличный пример fail-fast концепции.
Ты захотел вызвать функцию из библиотеки и передал туда то, что нельзя? — Ты узнал об этом как только написал код.
Ты хочешь понять из чего состоит ответ от сервера? Ты полностью видишь его структуру и понимаешь что можно и что нельзя с ним делать.
Возможно я просто не умею писать на динамических ЯП, но у меня ни разу не получалось сделать так, чтобы то, что я пишу — заработало без ошибок. Если это не print(1+10).
Создать маленький скрипт, строк на 20, чтобы нейросеточку обучить или там данные в R обработать и график вывести — это ок. Написать, ну хотя-бы нормальный калькулятор, так чтобы новые функции туда вводить парой строчек кода — уже мучения с отладкой и вопросы небу «Что я сделал не так»?
При этом в статическом ЯП я просто пишу и компилирую. И очень часто все работает как ожидалось. IDE отсекает за меня целый класс ошибок, просто не давая мне их сделать. По моему это прекрасно)
PS
А большая часть ошибок возникает там, где были приняты решения формата: «Нет, мы не будем создавать тип для этого перечисления, мы запихаем сюда Int и будем проверять на этапе исполнения».
А где раздают баны и триггерятся на "хак" и "взлом"? Просто интересно, никогда с таким не сталкивался. Вроде слова как слова.
Или ухудшить в случае если вы ошибетесь.
Это вы по личному опыту судите? Статистику дайте пожалуйста. Очень уж сомнительное утверждение.
А еще связи, подвешенный язык, время и куча прочих факторов, которые мы назовем «удача». Тут недавно была статейка с моделькой распределения благ в зависимости от таланта и случайных факторов. Совершенно внезапно, согласно ей случайность играет большую роль, чем талант.
А вы им предложили ровно те-же условия и ЗП в 2 раза больше или все же нет?
У меня вот спокойный проект, кучу времени (рабочего) посвятил саморазвитию, компания стабильна, коллектив меня радует, переработок почти не бывает, только в случае критических ситуаций (завтра клиентов на сервер пускать, а прод лежит после доставки). Переработки по собственной инициативе скорее возбраняются — гонят отдыхать)
Я что-то не уверен, что готов уйти крутиться белкой в колесе стартапа даже за x2.
Время, нервы и хорошие отношения с коллективом дорого стоят, а их не так уж просто найти в компенсационном пакете)
А вы серьезно думаете что врачи работают иначе?)
У них есть черный ящик, который сбоит, есть набор свидетельств в пользу разных гипотез о причинах сбоев. Исходя из свидетельств одним гипотезам присваивается большая вероятность, чем другим. И да, дальше идем ставить эксперименты — стало легче, значит, наверное помогает. Может помогло вообще не оно, но эту проблему решают на этапе тестов препаратов двойным слепым плацебо-контролируемым, с получением статистически значимых воспроизводимых результатов.
И да, я не отрицаю, что есть побочки, есть индивидуальная переносимость препарата, но если вы ничего не знаете про группу схожих препаратов, стратегия «взять первым наиболее эффективный согласно агрегации по куче исследований» — имеет смысл. Врач как ни странно, тоже не сверхчеловек и посмотрев на вас не предугадает какой препарат из группы вам зайдет, а какой нет.
Описанный вами случай с головной болью — вообще не в ту степь. Боль не усиливалась на холоде? И наоборот, не отпускало ли вас в тепле? Если помогал кофеин, то скорее всего за счет расширения сосудов. Или повышения давления. Возможно имел место спазм сосудов, но за несколько недель вы наверняка попробовали спазмолитики. Короче, это уже история про диагностику, а не выбор наиболее эффективного обезболивающего.
Вы тут где-то запутались. У головной боли действительно куча причин, но делать вывод что универсального обезболивающего нет — как то странно.
Почитайте механизмы действия ибупрофена, нимесулида, декскетопрофена, кеторолака. Обнаружите некоторое сходство.
Как ни странно, обезболивающее не лечит, а уменьшает боль, и для большинства доступных вам НПВС это происходит схожим образом.
Местная анестезия тоже работает более менее одинаково.
Депрессия может быть самостоятельным заболеванием, связанным с нарушением выработки кого то из троицы Норадреналин, Дофамин, Серотонин и лечится, как ни странно, препаратами которые разными способами повышают количество сих нейромедиаторов, например, угнетением их обратного захвата. Я бы с огромным удовольствием взглянул на статистику, по разного типа АД, и тому насколько они помогают, ибо это позволит хоть как-то понять распределение причин депрессии. Например, что чаще помогает СИОЗС/СИОЗСиД/СИОЗСиН?
PS
А врачи частенько те еще специалисты. Меня вот полторы недели гоняли с больной головой и охренительно опухшим лимфоузлом с одной стороны. Пока я сам не залез, и не прочитал что это может быть зуб мудрости. Голова прошла сразу после удаления единственного не вылезшего. Меня до этого наблюдало 6 врачей: лор, 2 терапевта, невролог, терапевт-стоматолог и хирург из омс-ной стоматологии — ни один из них не предположил что проблема в зубе мудрости.
Короче, врачи иногда тоже такая себе экспертная система. Хорошо знать хорошего специалиста, но с этим есть проблемы)
Просто поделился наблюдением, что логическая цепочка «вегетаринец/лесбиянка/феменистка -> фанатичен» не верна. Судя по моей (небольшой и нифига не репрезентативной) выборке, фанатики распределены среди групп людей в более-менее одинаковой пропорции. И именно на фанатизм и стоит обратить внимание, не важно является ли он социально приемлемым или нет.
В 7-9 лет… Не берусь судить, дети разные. Знаю таких, кто осилил бы. Да и начальные главы «лекций» и «вы конечно шутите», по моей памяти очень просты. Но, думаю, есть и специальная детская литература. Может, «Незнайка»?) Я читал только часть «на луне», но если остальные того же формата, должно подойти. Можно поискать еще что-то.
И всегда есть общение. Мои родители интересовались моим мнением, развернуто объясняли если я в чем-то не прав и старались не давить авторитетом в формате «ты маленький, а мы взрослые и знаем как лучше». Иногда, бывало и такое, но никто не совершенен.
Интересная у вас выборка, если она мотивирует вас защищать свою жизнь)
Моя небольшая, человек 5 вегетарианцев, несколько человек разделяющих феменестичные взгляды, ну и ещё человек 6 с нетрадиционными предпочтениями в сексе.
Никто из них не пытался насильно кормить меня фалафелями, не оскорблял за половую принадлежность и не тащил в постель. Так что ни желания, ни потребности жизнь защищать — не возникало.
Иногда о проблемах рассказывали, дескать рацион вегетарианцу составить трудно, или вот с парнем за ручку другому парню не походить — агрессивно настроенные личности могут наехать и дойти до рукоприкладства.
В общем, люди как люди, ничего необычного.
А отдельную выборку составляют, эм… Идиоты. В плохом смысле, а не клиническом. И такие были и среди "мужчина, белый, не вегетарианец, натурал" и среди "притесненных" всех мастей. И вот от кого хочется защищаться — так это от них. Если человек считает что правильно применять насилие к людям просто потому что они относятся к определённой группе, не разделяющей его взгляды — это, кхм, немного пугает. Оправдания у таких обычно разные: мой народ/группу притесняли, теперь я притесню их. Или "мне нужно защитить детей от их пагубного влияния". Или "они болеют за синих, но зелёные лучше!". Столько странных оправданий для несовершенства своих мыслей. Если вы причесали какую-то группу под одну гребёнку, если повелись на стереотип, если приняли мысль толпы, неподумав самостоятельно хотя-бы минуту — вы проиграли. Вы предали свою способность мыслить, а не подчиняться стадному инстинкту, предали то, что делало вас человеком.
Так что лучше дайте своим детям почитать Фейнмана. Пусть смотрят на мир сквозь очки здорового скептицизма и учатся думать своей головой.
У нас на проекте есть аналитик. Он не знает, как внутри работает андроид. Он умеет формулировать задачи достаточно подробно, чтобы я это реализовал. Обычно, то что я реализовал сходится с тем, что представлял аналитик.
Я не вижу зависимости между «Не умеет в программирование» и «Умеет писать требования».
Или вы сделали какой-то другой вывод, а я вас не так понял?
Вообще я не ожидал, что именно первая часть вызовет интерес, и собирался дальше писать про быструю фильтрацию для обеих сторон и текущую ситуацию с оценкой кандидатов.
Я смотрел на ситуацию со стороны «мне нужен сотрудник», а не «у меня огромный штат и мне нужно обеспечивать прибыль компании». Я работаю в небольшом отделе (15 человек или около того), с большими потерями на начальное обучение из-за того, что у нас много своих велосипедов. И когда в кандидата надо вложиться для получения результата это существенно меняет ситуацию. Совсем не хочется, чтобы человек ушел потому что ему не понравились печеньки)
Я совсем не подумал о том, что большинство участников рынка находятся в другой ситуации, у меня тут слепая область. Хотя, из стратегий подбора персонала тем же яндексом и гуглом можно было сделать выводы. В общем — ошибся, бывает)
Буду корректировать модели, соберу информацию и напишу отдельную статью. Думаю, стоит кластеризовать компании. Для мелочи, средних и бегемотов стратегии явно будут разными. И кандидат должен это учитывать.
(0.5/0.5)(1:0)
(0.25/0.75)(0.75/0.25)
Но, даже в таких условиях, ваше замечание про стратегию «быть честным» — отлично работает. Я не подумал о том, что экономия на сотруднике обманом или завышение сотрудником «стоимости себя» можно рассматривать как увеличение выигрыша одной стороны и проигрыш другой. Поскольку мы считаем, что обманутая сторона проиграет независимо от своей стратегии у нас получается ваша матрица игры.
Это работает даже если мы введем штраф с обманутого игрока и выйдем из бинарного случая проиграл/не проиграл. Штраф ведь останется один и тот же для каждой стратегии другого игрока. Например, кандидат сильно завышает цену, а компания недоговаривает об условиях. Предположим, что со стороны компании нанять сотрудника обманув, приведет к выигрышу +0.25 и такому же штрафу сотрудника, а сотрудник выиграет 0.5, если его возьмут по завышенной цене.
(0.5/0.5)(1:0)
(0.25/0.75)(0.25/0.25)
Спасибо за ценный комментарий, обновлю статью!
Есть вопрос с выкладыванием в сторы, но можно решать проблемы по мере поступления, а Android может и без этого обойтись.
Желтое — не звонят. — 0.9 круга.
Зеленое — оффер. — 0.2 круга.
Зелено-желтое — оффер и не звонят. Отношение зеленое/зелено-желтое — 0.4.
Мне нужно узнать вероятность, что я нахожусь в пересечении, зная что я уже в желтой области, и зная, какая часть зеленой области пересекается с желтой. Умножаем 0.2 (зелененькое)*0.4 (отношение зеленого и зелено-желтого) — узнаем какой кусочек всего круга — зелено-желтый. Теперь надо узнать какой кусочек желтой области — зелено-желтый. Зная, что желтая область — 0.9 от всего кружка получаем соотношение 0.2*0.4/0.9. Вот и вся теорема.