Комментарии 202
if (isPrepared) {
return true;
else if (!isPrepared) {
return false;
} else {
return !true && !false;
}
function getDevJob(studying, hardWork, luck) {
switch(studying){
case true:
switch(hardWork){
case true:
switch(luck){
case true: return true;
case false: return false;
}
case false: return false;
}
case false: return false;
}
}
default забыли!
function getDevJob(studying, hardWork, luck) {
return (studying && hardWork && luck) ? true : false;
}
Первичный «индусский» вариант куда как легче читается, чем эта оптимизация.
За 15 лет работы мой мозг почти каждый день тренируется чтением подобных конструкций. И тем не менее я считаю подобную оптимизацию далеко не всегда уместной.
Имхо, средний уровень программистов (а рассчитывать на то, что за тобой будет читать не сверх-выскоко-квалифицированный, а самый обычный программист, такой вот школьник как автор оригинала статьи — вполне нормально) не настолько высок, чтобы напрягать их мозги без повода.
Пусть лучше напрягают мозги по сути решаемой прикладной задачи, а не по причине невнятного синтаксиса.
Я сам, в основном, пишу тесты на Java и с JavaScript знаком слабо…
иф бессмысленный, когда можно сразу сделать
return isPrepared
или даже сразу return без заведения переменной
«Неиндусский» переоптимизированный код читается ничуть не лучше.
Что нечитаемого в строчке return studying && hardWork && luck;
? Тут нет никакой хитрой магии, обычное вычисление.
Преждевременная оптимизация — корень всех проблем в программировании (Donald Knuth).
studying && hardWork && luck есть в исходном примере, почему вы это называете perl-подобной конструкцией?
Тогда уж
return !!isPrepared;
Только стоит ли сокращать эту запись, если как минимум 6 шутников в комментариях сократили её некорректно? Вопрос далеко неоднозначный.
return isPrepared > 0;
Это более хрупкий вариант… в текущем JS сработает, а в других языках не получится сравнить 0 и boolean. А это тоже допустимый вариант, если допустим hardWork — boolean, a luck — число от 0 до 10. Так что либо !!, либо явное приведение:
return Boolean(isPrepared);
раз такой зоопарк, то может не стоит писать в лоб через &&
а через
isPrepared = hardWork && luck > 0 && etc > 42;
Это отличный вариант для строго типизированного языка. При динамической же типизации у вас нет контракта какого типа аргументы придут в функцию. hardWork внезапно может оказаться undefined.
Поэтому как не изголяйтесь, а явное приведение к boolean будьте любезны написать, раз функции требуется возвращать именно true/false. Забыть про это приведение — типичная ошибка новичка.
Кол-во минусов к моему исходному комментарию показывает только то, что есть немало людей, которые пишут код на JavaScript ещё хуже, чем автор статьи. При этом они сами пока об этом не догадываются… недостаток опыта он такой, даёт ложную уверенность в своей неправоте :-)
Откуда берется требование выдавать на выходе корректные входные данные при некорректных входных? Почему аргументы могут иметь произвольные типы — а функция вдруг обязана вернуть булев?
Ну, а что такое рефакторинг? Это улучшение кода без изменения его API. Исходный код всегда возвращает либо true, либо false. Требований у нас нет, значит мы при переписывании кода обязаны подразумевать что такое требование было. И результат итоговой функции должен совпадать с результатом исходной на всём множестве значений аргументов. Мы тут не вдаёмся в причины этого требования, может результат надо было запихнуть в JSON и отправить какому-нибудь микросервису на Go (вот он обрадуется, когда получит "undefined" вместо false).
Но причины требования не суть важны в данном примере, важно, что сохранность API — это базовые основы рефакторинга. И куча людей этого не понимает, что уже печально. Получается, хотели показать как они круты, переделав код из статьи, а по факту опозорились. Но не в силах признать ошибку, предпочитают заминусить… Ну ладно, желаю им профессионального роста. Может через пару лет поймут, что признать ошибку не стыдно, стыдно — не признать )))
Вы были бы правы — если бы речь и в самом деле шла о рефакторинге. Я же утверждаю, что данная функция изначально должна была быть написана по-другому.
Я же утверждаю, что данная функция изначально должна была быть написана по-другому.
На основании чего? Это уже исключительно Ваши домыслы.
Мы обсуждаем варианты переписать существующую функцию, не имея никаких явных требований (есть только те, что заложены в код)… Это рефакторинг в чистом виде и ничто больше.
Вы же мотивируете только тем, что "автор — дурак, потому что я так считаю"… Это непрофессионально и все эти сокращения по факту оказываются дешевыми понтами, если не можешь сократить без изменения поведения кода.
Но причины требования не суть важны в данном примере, важно, что сохранность API — это базовые основы рефакторинга.Реализация — это не API. API — это описание параметров и результатов. Подкреплённое тестами, в идеале.
Устраивать рефакторинг не имея представления что ваш фрагмент кода делает и когда он используется — кончается слезьми.
Я бы, к примеру, объявил результат при передаче не-булевых параметров неопределённым. Или сказал бы, что получаем false если все параметры false.
Но стараться «сохранить жизнь» программе когда она уже «слетела с катушек» — приводит скорее к тому, что ошибки загоняются вглубь, чем к тому, что они исчезают.
Реализация — это не API. API — это описание параметров и результатов. Подкреплённое тестами, в идеале.
И что? В данном случае, единственное описание API — это сам код. Так тоже бывает.
Устраивать рефакторинг не имея представления что ваш фрагмент кода делает и когда он используется — кончается слезьми.
Ну так я и пытаюсь эту мысль донести. Если делаете рефакторинг без явных требований, то не меняйте соответствие между входными параметрами и результатом для всего множества входных параметров.
Ну или не плачьте, когда прод упадёт :-)
Но стараться «сохранить жизнь» программе когда она уже «слетела с катушек»
В чём тут "слёт с катушек"? Вы ни разу в жизни не писали функций, которые должны строго возвращать boolean? Не так уж редко именно это и требуется, вне зависимости от входных параметров. Ваши фантазии на тему неопределённых результатов имхо оффтопик.
Если делаете рефакторинг без явных требований, то не меняйте соответствие между входными параметрами и результатом для всего множества входных параметров...То вы уже в стадии, когда стоит поискать другую работу.
Либо вам дают время на то, чтобы разобраться что оно такое тут должно было делать и как-то это задокументировать, либо ком «технического долга» будет стремительно нарастать, пока всё это не развалится к чертям собачьим. Хорошо бы, чтобы вас в этот момент поблизости уже не было.
Вы ни разу в жизни не писали функций, которые должны строго возвращать boolean?Притом что они получают мусор?
Не так уж редко именно это и требуется, вне зависимости от входных параметров.Зачем? Чтобы сделать веселее отладку? Если вам нужно общаться с «сумасшедшим внешним миром», откуда приходит чёрт знает что — введите слой, где вы всё приведёте в норму, флажки станут bool'ами, количественные величины — числами и т.д. и т.п.
А дальнейшую работу уже ведите не мучаясь с тем, что у вас в каждой строчке каждой функции мина может быть. Closure, TypeScript не зря появились, ох, не зря.
Вы утрируете. Полно случаев, когда можно слегка улучшить код по ходу дела, не меняя его поведения и не разбираясь, как можно/нельзя изменить его поведение. И в любом случае, если Вы хоть как-то измените поведение, то это уже будет не рефакторинг. И лучше это делать отдельным коммитом, когда надо.
Притом что они получают мусор?
Почему мусор? undefined — это вполне рабочее значение в JavaScript. Нравится Вам или нет, но факт в том, что это так.
P.S. Слушайте, я тоже не в восторге от JS и вообще фронтом практически не занимаюсь… но там сам JS-мир слегка сумасшедший, Вы конечно можете старательно огораживаться, не принимая их практики, но смысла мало.
return studying && hardWork && luck;
— вместо всего того что на картинке
Например в тех, где bool может быть отличным от 0 и 1. Потому что на выходе будет тоже значение отличное от 0 и 1. В тоже время иногда быват важно, что функция возвращала строго 0 или 1.
Соответственно функция возвращающая bool вполне может возвращать значение отичное от 0 или 1.
А это бывает критично. Например, для записи в бинарном виде.
Строго лексемы true или false, которые эквивалентны 1 или 0, а не логические true или false, в которых true может быть отличным от 1.
На картинке прошу заметить используется именно этот оператор, а не проверка каждой переменной отдельно.
true вернет. Только не 1, а 2
Вы наверное удивитесь, но есть языки, где конъюкция не делится на логическую и бинарную.
Назовите, пожалуйста, язык, в котором оператор && (логическое «И» в любой форме) возвращал бы что-то кроме true или false.
Уууу, есть многое на свете, друг Горацио…
SELECT TRUE AND NULL;
JavaScript, Python, Lua, Ruby. Первые что в голову пришли, на самом деле намного больше.
Кстати && там — «исключающее или».
«Добро пожаловать в реальный мир», сэр.
А вот if (b) return true else return false — это зло, да.
function getDevJob(studying, hardWok, luck) {
return studying && hardWok && luck
}
или модно, стильно, молодежно
const getDevJob = (studying, hardWok, luck) => studying && hardWok && luck;
Зачем тратить время на вызов.
Вас бы тоже на работу не взяли. Если уж писать дефайн — надо хоть скобки поставить...
А вообще конечно мне решать, а не компилятору, компилятор следует указаниям. Раньше вполне приходилось для простых вещей, вроде swap BGR -> RGB, делать ассемблерную вставку, иначе компилятор не мог нормально «решать».
Второй вариант хуже: нет поднятия, нет имени функции при отладке.
function getDevJob(studying, hardWork, luck) {
return studying && hardWork && luck;
}
if (true) {
return true;
} else {
return false;
}
А если всего лишь предположить, что функция обязана вернуть bool, то код выглядит совсем не бессмысленным. Потому что, на секундочку, в JS 1 && 2 — это 2, а не true (как раз кто-то там ниже спрашивал о языке, в котором && возвращает не bool… сюрприз!). Входные данные тоже могут быть разные — их может не быть (undefined), они могут быть не bool (тогда сработает приведение типов). Так что isPrepared совсем необязательно будет bool вообще.
И в результате, единственной оптимизацией, которая бы не изменила поведение функции, была бы замена блока if на return !!isPrepared;, с принудительным приведением типа двойным отрицанием. Тем, кто пишет на js регулярно, эта запись привычна. Для остальных, пожалуй, удачнее была бы запись return Boolean(isPrepared);
Господа, уточняйте постановку задачи :)
Очередная наколенная поделка по быстрому срубанию бабла…
То есть пишут что ищут джуниор девелопера на зарплату в 70К, например, а в требованиях перечисляют то, что соответствует квалификации синьора
В Штатах принято, при собеседовании, говорить что вы знаете и умеете всё что требуется работодателю. Какие бы требования он не выставлял.
Не знаете как взять интеграл, а в требованиях есть пункт что надо знать как их брать — говорите что умеете это делать, если хотите там работать.
P.S.
Сколько зарабатывают инженеры с визой H-1B в Facebook и EPAM
За такую 10% такой зп можно иметь карманного индуса за океаном, которому аутсорсить всю свою работу :)
У них сейчас популярна тема фейкового опыта.
Т.е. есть у них смышленые соотечественники, которые создают несколько фирм и за денежку обеспечивают трудовой стаж желающим.
И это работает, черт возьми!
Каким то образом некоторых потом берут в нормальные конторы, до поры до времени, естественно.
Ну а дальше они просто увольняются и идут на новое место.
Там просто сертификация потоком, ну, как у нас оплата проезда в маршрутках.
В общем такие "сертифицированные" "спецы" на рынке пишут вот такоэ
Или там не как у нас?
А че, у нас кто-то смотрит на рекомендации???????????????????????????????
Ну смотрят, конечно. Изредка. Это не само собой разумеющееся.
Как раз именно наша общепринятая безрекомендательная система как раз позволяет надувать одного работодателя за другим.
Легко.
Зачем им вообще нанимать фриленсеров, тем более в тридорога — если у них имеется целое отделение в РФ?
Да и вообще — найм фриленсера напрямую корпорацией?
Корпорацией?
Если конечно это действительно корпорация, а не одно название…
Думаю, это просто пустое бахвальство, а вовсе не реальные факты.
Как по мне — вполне себе «great article, whaaayyy». Вы не согласны?
Это одна из причин, почему там недоученные джуниоры получают в разы больше, чем местные кулибины с гигантским самомнением.
“There are no two words in the English language more harmful than «good job».” ©
betsuni > А у них, что ни история, то первый комментарий «great article». А что в ней great?
Ноги растут отсюда:
Там приведён практический алгоритм почему они именно так поступают, а мы нет.
Напомнило ситуацию из сериала Silicon Valley (1 или 2 сезон), когда Башку взяли в Hooli, а когда поняли, что он нихрена не может — его сняли с проекта и отправили на 3 года (контракт) гулять за зарплату.
то модель, в которой людей принято поощрять, даже если некоторые из них не совсем этого заслуживают, является более эффективной
Мечтать не вредно.
Но на самом деле не является. Проверено.
- Люди или заносятся, считают, что они круты на самом деле, если им много бабла платят.
- Или постоянно боятся, что они на своем месте незаслуженно и легко его могут потерять. Живут в стрессе.
Редко-редко, кто адекватно воспринимает такое преждевременное поощрение.
P.S.:
И для последующего трудоустройства это медвежья услуга как самому сотруднику так и будущим нанимателям.
У американцев первый позыв — похвалить, подбодрить, clap clap clap (даже если, прямо скажем, не за что).
Проводились исследования.
Наши улыбки — это знак личной симпатии.
Американские улыбки — это признак вежливости, не более того.
Я за того, чтобы по улыбке можно было личную симпатию определить.
То же самое и с похвальбой за успехи чисто из вежливости.
Она может и подбадривает
Но еще и дезориетирует.
У меня была девушка, которая меня хвалила.
Потом появилась другая, которая не стеснялась говорить, что мол одежда грязная, да прическая не красивая, да живот большой.
Я стал обращать внимание на эти вещи — лучше одеваюсь, занимаюсь спортом и пр.
Первая оказала мне медвежью услугу. Хотя мне с ней и было комфортнее, но комфортнее ничего не делать, не развиваться, не совершенствоваться.
Благодаря рациональному взгляду на меня второй я сейчас могу пробежать 50 километров и после этого отлично себя чувстовать.
В принципе обе точки зрения имеют силу.
Все зависит от того кого вы хотите взростить.
Разумеется мера нужна в обоих точках зрения.
Есть знакомые, которые на личном опыте оспорили Ваш комментарий. И даже как-то работали (около года), опыта набирались…
приходит куча людей на вакансии сеньёров и тех-лидов со знаниями от силы на джуна. то есть люди вообще не знают базы и видно что у них нет ни опыта ни понимания как работают многие вещи.
Так то отсутствие опыта не так то просто и скрыть.
Я в своё время после курсов не стал заливать что я мидл, а честно сказал что нет опыта. Меня взяли и я н практике понял что отсутствие опыта в рабочем процессе не скрыть. У нас была маленькая команда с ежедневными коллективными код-ревью (мега-полезная штука для развития). И за пару лет мне таки удалось наработать хороший опыт и начать разбираться в предмете.
Не раз сталкивался с мид/сеньер кандидатами, которые утверждали «я очень круто умею ставить кнопочки на форме и верстать UI, но знать не знаю и не хочу знать про стек и очередь, спросите лучше про кнопки».
Для человека, который делает формочки, база — это не стеки и очереди, а. внезапно, API контролов.
От специалиста по формочкам ожидается, что:
- он не спасует когда понадобится показывать на форме произвольное (определяемое во время исполнения) количество кнопок;
- он знает как выносить в фон длинные операции;
- он не испугается, узнав что интерфейс надо делать на нескольких языках;
- его формочки адекватно отображаются на мониторах разных разрешений;
- в его коде нет метода
button76_Click
.
Вопрос закрыт.
Millennials in the Workplace Training Video
Ох уж эти миллениалы.
Одна компания использовала это против меня и предложила мне 60000$ (столько предлагают младшим разработчикам).
А разве автор оригинального текста не является именно младшим разработчиком? Не пойму чему именно он возмущается.
Велика разница…
И таких очень много. 45 миллионов американцев не имеют страховки вовсе.
http://argumenti.ru/rassledovanie/n415/299863
Из-за высоких цен на медобслуживание ежегодно умирают десятки тысяч американцев. Каждый шестой гражданин США не может себе позволить медицинскую страховку. А это значит, что в случае серьёзной болезни ему придётся рассчитывать только на себя. Волонтёры североамериканского офиса Стрингерского бюро международных расследований собрали сведения о самой болезненной для сегодняшней Америки проблемы – заоблачной стоимости медицины.
Простите, но у нас такого беспредела нет — чтобы 45 мл. населения вообще не имели доступа к мед. помощи. Это чисто американская особенность.
А еще есть те, у кого минимальная страховка, покрывающая только простейшие ситуации. И таких уже — подавляющее большинство.
В реальности хорошая медицинская помощь типа как в «Докторе Хаусе» доступна только 15% американцам.
Американцы с хорошими окладами, как правило, автоматически имеют хорошую страховку.
Так и у нас те, кто имеют хорошие зарплаты — вполне могут лечиться у хороших медиков.
Никакой разницы.
Разница только в том, что у нас меньше оклады, но и страховка из окладов не вычитается.
США — единственная из ведущих индустриальных держав, не принявшая систему обязательного медицинского страхования.
108 млн. американцев не могут себе позволить сходить к зубному врачу.
У 45 млн. американцев нет мед. cтраховки,
среди них 10 млн. детей.
… Потому американцы исправно кормятся многочисленными таблетками и витаминами ежедневно, надеясь избежать встречи с врачом.
Ежегодно почти сто тысяч человек по всей Америке гибнут из-за медицинских ошибок
Среди людей, лишенных медицинской помощи, около 88% работают, но многие не зарабатывают достаточно для того, чтобы оплатить частную медицинскую страховку. В то же время они не могут получить государственную страховку для бедных, поскольку их доход превышает официальный уровень бедности. В случае неоплаченного лечения действует право наложения ареста на имущество должника и человек может остаться бездомным, так как медицинские счета легко могут составить 20 тыс. долларов и более.
Однако дороговизна медицинского обслуживания не гарантирует его добросовестности.
По оценкам, более половины смертей в госпиталях можно было бы предотвратить.
… американцев с годовым семейным доходом 9 тыс. долларов и менее умирает в три раза больше, чем американцев с семейным доходом 25 тыс. долларов и более.
Все дорогостоящие виды медобслуживания зачастую назначаются только ради выгоды, чтоб выбить максимум денег из пациентов. Врачи в принципе не заинтересованы в излечении больного, т.к. это лишает их доходов.
Потому в США один за другим проходят процессы, где пострадавшие пытаются отсудить у клиник деньги за навязанное им «лечение», которое не только разоряет огромное количество людей, но и может окончиться инвалидностью или смертью.
Средний период ожидания в отделениях скорой помощи США составляет 7 часов. Если больной не доставлен в больницу на машине «скорой помощи», то существующая процедура требует, чтобы он зарегистрировался в регистратуре, а потом медсестра проводит поверхностный осмотр чтобы определить сложность ситуации. После этой процедуры больной может часами ждать осмотра врачом. Если, при всем этом, требуется сдать анализы или сделать рентген, то ожидание может занять более 12-ти часов.
в США подан иск против компании Tenet Healthcare Corp., владеющей сетью из 114 больниц в 16 штатах и обеспечивающей их работу. Руководство компании и восемь врачей ее клиник обвиняются в систематическом проведении не требовавшихся операций на сердце. 51 пациент из 366 перенесших операции на сердце без необходимости скончался. В иске говорится о том, что смерть некоторых из них наступила в результате перенесенной операции.
Как когда-то говорил Михаил Жванецкий, «Америка – хорошая страна, пока не заболеешь».
В Америке можно позволить себе заболеть, только если вы зарабатываете очень большие деньги или являетесь знаменитостью.
Медицина в США, как и все остальное, основана на делании денег, а вовсе не на помощи людям – со всеми вытекающими отсюда последствиями. Если в России врачами становятся по призванию, то здесь это делают в подавляющем большинстве своем ради денег. Результаты этой системы очень плачевны, а наличие медицинской страховки дает лишь частичное облегчение.
Если вы хотите, чтобы ваша страховка все покрывала, и чтобы вам не нужно было доплачивать ничего из своего кармана, то вы приехали не туда. Если вы хотите доплачивать минимум, то вам придется месяцами ждать разрешения на прием у специалиста, к которому вы можете попасть только по направлению лечащего врача, и обоих вы можете выбрать только из списка, предоставляемого вам страховой компанией.
Другой вариант заключается в том, что у вас есть относительная свобода выбора специалиста (правда, тоже по списку) без направления лечащего врача, но в этом случае вам придется доплачивать, как правило, 20 процентов стоимости всех медицинских услуг из своего кармана. В дополнение к страховке, конечно.
Если вам понадобилась срочная помощь, а врач, оказавший ее вам, не входит в предоставленный страховой компанией список врачей, то вам придется заплатить по полной стоимости, что составляет в среднем около $200-$300 за один прием! У вас есть страховка? Нет, у этого врача нет контракта с этой страховой компанией. Извольте заплатить по полной стоимости!
Чтобы не быть голословным, приведу пример. Наш сосед по дому сломал ногу и летал в Москву накладывать гипс, потому что ему перелет туда и обратно плюс неделя проживания в Москве обошлись дешевле, чем стоила бы накладка гипса в любом местном госпитале!
Я вскоре сам убедился в правдивости его слов, когда мне сделали операцию по удалению дефекта косточки на большом пальце ноги. Операция длилась всего час и стоила $7000, из которых $1500 я заплатил из своего кармана. Это при том, что я плачу за медицинскую страховку $350 каждый месяц.
Ведь действительно мне было бы дешевле слетать в Москву, где мне бы сделали эту же самую операцию за одну десятую стоимости в лучшей клинике не менее квалифицированные специалисты, плюс у меня бы еще остались деньги на цветы для женщин и на обед с ними же в хорошем ресторане.
К сожалению, безумная стоимость медицинского обслуживания это еще полбеды. Найти хорошего врача в Америке сложнее, чем белые грибы в феврале у стен Кремля.
Когда я обратился к ортопеду с болями в ноге (я много играю в футбол, поэтому травмы ног для меня – нормальное явление), он сделал мне рентгеновский снимок. Посмотрев на него, врач с умным видом заключил, что он ничего не видит на нем, и у меня вскоре должно все пройти само собой. Я уже тогда перестал сомневаться в квалификации этого гения мировой медицины, но на всякий случай поинтересовался, почему у меня в течение шести предыдущих месяцев ничего не проходило. В ответ он пожал плечами и сказал, что он просто не имеет понятия. Больше информации из него вытянуть мне не удалось. В итоге, я потратил еще год на хождения по врачам, пока не нашел такого, который мне смог поставить диагноз и вылечить проблему единственным уколом!
Это всего лишь один пример из моих многочисленных столкновений с хваленой американской медициной. Не буду их приводить здесь, но могу с уверенностью утверждать, что такого уровня некомпетентности и безразличия к больному невозможно представить ни в одном страшном сне.
По последним данным, из 19 цивилизованных стран США имеет самое низкое качество медицинского обслуживания, которое выражается, как это ни печально, в самой высокой детской смертности. (KABC Radio) (46)
· Шестьдесят миллионов американцев (практически четвертая часть населения) не в состоянии оплатить себе ежегодную медицинскую страховку. То есть все эти люди вынуждены выбирать между оплатой страховки, что равнозначно для них практически полному разорению, и существованием без гарантии покрытия расходов на медицинское обслуживание.
В последнее время в стране, где работают лучшие в мире врачи и построены лучшие в мире больницы, ситуация с медицинским обслуживанием значительно ухудшилась. В Техасе, например, из-за урезания финансирования число детей, не получающих бесплатного медицинского обслуживания, увеличится еще на 275000 человек. Этому американскому штату уже принадлежала пальма первенства в области лишения детей права на бесплатную медицинскую помощь — наследие, оставленное прежним губернатором Джорджем Бушем.
На одной из встреч с губернаторами штатов американский президент заявил, что они не должны рассчитывать на Вашингтон при решении своих финансовых проблем: «Мы живем в очень сложное время, страна находится в состоянии войны». Но и после окончания войны по-прежнему нет возможности компенсировать лечение и медикаменты неимущим больным. Драконовские налоги, установленные для производителей табачных изделий, и прочие меры, принятые в экстренном порядке, практически ни к чему не привели. И все это, не говоря об астрономических ценах на медикаменты — в Соединенных Штатах лекарственные средства стоят дороже, чем в любой другой стране мира, и при этом фармацевтические производства получают до 73% прибыли. Многие из американцев вынуждены ездить в соседние Канаду и Мексику, чтобы покупать там необходимые им лекарства. Особенно остро эта проблема стоит во Флориде — золотом раю для пенсионеров: в Соединенных Штатах затраты на лекарственные средства у людей пожилого возраста составляют 3000 долларов в год. (129)
· Проблема медицинской помощи — одна из острейших в США. Расходы на медицину составляют астрономическую сумму — примерно 14% ВВП страны, при этом многие жители США не имеют средств на оплату визита к врачу и покупку лекарств. В 2003 году среднестатистический житель США потратил на медицинские цели $5 440. Жители США потратили на медицинские цели на 9.3% больше, чем в 2002 году. При этом, затраты на покупку медикаментов выросли более, чем на 15% (все данные правительственной организации Centers for Medicare and Medicaid Services). К примеру, стоимость посещения терапевта, в среднем по стране, составляет $120. В среднем по США, медицинские расходы на душу населения (расходы, которые житель США оплачивает из собственного кармана или погашает страховая компания) составляют $3 759 в год. Ежегодно более 18 тыс. американцев погибают только из-за того, что у них нет медицинской страховки, и они не в состоянии оплатить медицинскую помощь. Согласно исследованию, проведенному Institute of Medicine (негосударственной организации, проводящей независимые экспертизы в медицинской сфере для Конгресса США), незастрахованные люди, у которых обнаружен рак груди, имеют на 50% больше шансов умереть, чем застрахованные. Также значительно больше шансов расстаться с жизнью у жертв несчастных случаев, диабетиков и гипертоников. 77 млн. американцев имеют так называемую «прерывную страховку», т.е. в определенные периоды не имеют никакой (например, в случае потери работы).
Называется «медицинский туризм». Термин удостоился помещения в Википедию, значит, довольно устоявшийся термин.
Медицинский туризм даже внутри РФ.
Скажем, москвичи любят лечить зубы в провинции.
И туризм и сэкономил. А качество — то же.
Хорошие стоматологи в крупных провинциальных городах РФ используют ровно те же технологии, что и их собраться из США.
За исключением особо сложных медицинских случаев и штучного оборудования ведущих клиник — услуги ровно те же.
P.S.:
Но, как правило, это делают, летая в гости к родственникам.
В цитате упомянуто, что люди иногда летают из США в Москву (очевидно, выходцы из РФ).
К нам в провинцию из Москвы прилетают на побывку и полечиться детки тех, кто живет здесь.
https://www.healthcare.gov/fees/fee-for-not-being-covered/
Я не буду приводить пруфлинки на неизвестно кем и с какой целью написанные статьи, а дам собственные примеры.
— В январе в США делали операцию по удалению жёлчного: лапораскопия за час-полтора, полчаса на отходняк и — домой; три дня не делать резких движений. Хирурга нужно выбрать из списка, но список достаточно велик. Общая стоимость всего медобслуживания с предварительной диагностикой и лекарствами вышла ~36-38 тыс. долларов. Из кармана пришлось заплатить ~1200-1300 со средней зарплаты сениора, и это размазано на несколько месяцев. Лекарства, кстати, тоже покрываются страховкой значительно.
— В октябре в США у подруги, приехавшей в гости возникла резкая боль в брюшной полости, пришлось вызывать скорую. Американской страховки у неё, конечно же, не было. Разговор по телефону занял 3 минуты, скорая была на месте через 6 минут (ночью дело было). В больнице скорой нашли русскоязычного медицинского переводчика минут за 5. Сделать успели ЭКГ, УЗИ, биохимию крови, записать историю болезни, полечить уколами и микстурами, прописать дальнейшее лечение и назначить визит к гастроэнтерологу. Оказалось обычным, но очень сильным пищевым отравлением, и дальнейших расходов не повлекло. В итоге всё суммарно обошлось ~2500 долларов. Один важный нюанс: при выходе из скорой заплатить пришлось 350. Счета на остальное идут частями и будут идти ещё с полгода, так что продавать машину/квартиру/почку для оплаты таких счетов не придётся.
Прошу всех извинить за этот эмоциональный оффтоп, не могу удержаться, когда обсуждение превращается в Вести недели.
В январе в США делали операцию по удалению жёлчного: лапораскопия за час-полтора, полчаса на отходняк и — домой; три дня не делать резких движений. Хирурга нужно выбрать из списка, но список достаточно велик. Общая стоимость всего медобслуживания с предварительной диагностикой и лекарствами вышла ~36-38 тыс. долларов. Из кармана пришлось заплатить ~1200-1300 со средней зарплаты сениора, и это размазано на несколько месяцев. Лекарства, кстати, тоже покрываются страховкой значительно.
Ровным счетом никакого противоречия.
Вы — сеньор.
С соответствующей страховкой.
Подавляющее большинство людей имеют куда как меньшие доходы.
И старховки. Если имеют.
В Америке хорошо болеть богатым.
И тем, кто зарабатывает достаточно, чтобы у него была хорошая страховка.
Только и всего.
Так что нет никакого противоречия.
Согласно открытой и свежей статистике — у 45 миллионов в США нет страховки вообще.
А у еще 100 млн. страховка стрёмная, по которой даже зубы не вылечишь.
И т.д.
Вы занимаетесь демагогией. Ещё и опирающейся на *устаревшую* статистику, так как сейчас приведённые цифры заметно ниже, что показывает прогресс.
Ну и про страховку зубов: в США она, как и страховка зрения — это отдельные статьи, не связанные с общей медстраховкой, они часто даже предоставляются отдельными страховыми компаниями. Моя страховка зубов обходится $6-8/мес, а зрения — в два раза дешевле. По-моему, такую сумму нетрудно платить даже с пособия.
Беларусь. Обострение жёлчного. Лапароскопию не стали — потому что — как сказали — обострение.
Полосная операция. 2 недели в больнице. 2 недели дома.
2000 год. 25$ на руки анестезиологу (он у них был за «поговорить об операции» и для сбора денег).
Продавленные кровати. Еда нормальная. Но матрацы с комками ваты запомнились.
2000 год. Минск. Больница Скорой Помощи. Операции там такие идут потоком непрерывно.
Да, был у них ещё «телевизор» — дырка в животе и туда вводят камеру со светом. Я отказался. Не хотел дырку в животе получать. Это обозлило хирурга. Вот он меня и располосовал.
Узи камень нашло на третий раз (на второй день)
Плюс ситуация не одинакова по США, а варьируется от штата к штату. В большинстве «демократических» штатов программу medicaid расширили и она покрывает всех, чей доход ниже 26К в год, а людям со средним доходом дает скидки на покупку страховки. В «красных» штатах, которые последние несколько лет потратили на борьбу с обамакеар, это расширение не приняли, в итоге в некоторых штатах бесплатная страховка положена только людям с годовым доходом менее 3000. При стоимости страховки в 300-1500 в месяц в зависимости от состава семьи, понятно, что семья с доходом в 20 000 вряд ли сможет себе страховку позволить. Так что остается только обслуживаться за деньги, и объявлять банкротство, если грянет гром.
А дальше, научил других.
Искать специалиста сложно. Как правило, нет того кто будет работать так как надо сразу. А значит у него есть время на старте, пока его не раскусят. А у самого есть шанс надорваться.
По моему, лучшее решение, это честно говорить о себе и занять позицию интерна в желаемой компании. Потом качать скиллы пару лет…
Тоже недавно искал работу на западном рынке. Отвечают очень мало, судя по письмам, 1-2%. Процесс очень долгий, будте готовы ждать до 3-х месяцев.
просто то как это сейчас написано коробит глаз! (;
«Я провел 3 месяца, пытаясь устроиться на работу после лагеря программирования, и вот чему я научился»
Писать напрямую спецам в обход HR — моветон, можно сразу получить бан.
98% программистов занимаются всю жизнь работой, которой их вполне могли бы научить в ПТУ и техникумах.
ВУЗ — это пережиток времени, когда профессия программиста была элитной-штучной. Это лет 30 тому назад было.
Оставщиеся 2%, действительно, занимаются очень серьезными вещами — для которых, парадокс, вузовского образования уже недостаточно.
ВУЗ программистам не нужен.
Но курсы длинной в 3 месяца — это перебор, конечно.
Нужно хотя бы 2 года обучения.
Меня тоже расстраивает когда кто-то не может TCP от UDP отличить. Вот только, к сожалению, ВУЗ — не гарантия наличия подобных знаний...
Основы HTML нам в свое время рассказали за 30 минут.
Основы TCPIP — за 20 минут.
;)
Если кто-то сказал вам, что этому нужно учить годами — то тот просто тупо хочет денег.
Не учить тебя, Карл,
а просто взять твои деньги, Карл.
Да, есть те, кто способен и сам это освоить, но будет это куда дольше. И это скорее исключение из правил.
Да, ВУЗ не гарантирует того, что специалист выйдет годный, но отсутствие ВУЗа с большей вероятностью гарантирует, что ничего путнего работодатель не получит.
Для того, чтобы клепать формочки или верстать странички — выходящая за рамки школьной программы математика не требуется.
И уж точно программисту не нужны философия, социология и культурология.
Т.е. вы считаете, что теория это бред? ВУЗы помимо того что учат тупо ЯП, дают хорошую теорию, математику, физику и т.д. Учит в принципе работать правильно, работать с литературой и самое главное — Расставляет акценты.
Кому нужна физика?
Админам? 1С-никам? PHP-истам?
Математики для работы 98% программистов достаточно на уровне 6-7 класса школы. Даже не 10-11.
А учить работать с литературой 4-5 лет — это чрезвычайно расточительно.
А когда даже с вуза приходят студенты на собеседования и смотрят в книгу, видят фигу, видимо даже и этого недостаточно. И опять же поглядеть на тостер, 99% вопросов потому что лень книжечку почитать или просто отсутствует понимание того, что это куда лучше, чем просто ждать, пока за тебя кто-то сделает.
Вы так пишите, как будто каждый программист занимается какой-нибудь обработкой данных...
Ах да, других же программистов не бывает
ОК, давайте добавим сюда фронтендеров (не тех, что игры делают, где, возможно и понадобится какая-то математика/физика, а возможно и нет).
Админы, PHP, 1C, фронтенд — это 90% программистов.
Насчет компиляторов — это смешно.
Вы сами-то хоть один компилятор в мире написали?
А ваши знакомые?
Мне не нужно знать как бегают электроны и какие они создают магнитные поля — чтобы просто включить лампочку. Очень жаль вас, если вы без этого знания боитесь подойти к выключателю или розетке.
А когда даже с вуза приходят студенты на собеседования и смотрят в книгу, видят фигу, видимо даже и этого недостаточно
Напротив.
Нужно сокращать до 2 лет.
Фигу вполне можно научиться видеть за этот срок.
Встречал таких более чем неоднократно.
В среднем 1 раз в 2 года в небольших конторах.
2 раза в год в больших конторах.
Действительно, можно получать больше денег, чем стоит твоя средняя квалификация на рынке.
Это касается не только ИТ
Видел такое и среди ИТ-шников и среди менеджеров и пр. и пр.
Поскольку там не 5 и не 10 процентов разницы, а бывает и в 2 раза выше оклад — то усилия по бомбардировке 300 фирм запросами вполне оправдываются.
Не статья, а просто какой-то кошмар работодателя. Расскажу со стороны собеседующего: разместили вакансию, и тут поперли косяком люди с красивыми резюме, но в программировании ни в зуб ногой. Почти всем хватило трех простых вопросов:
- расскажите об особенностях быстродейтвия ArrayList vs LinkedList
- напишите программу, которая читает текстовый файл с диска, сортирует в нем строки и сохраняет в другой файл
- напишите рекурсивную функцию, вычисляющую максимальную глубину дерева.
А на каждого надо тратить время...
20 лет реального опыта.
Первый вопрос. Не знаю что это за *List, я вообще в другом языке спец, не в этом.
Ну разве что косвенно по названию, что первый — массив, следовательно доступ по простой прямой адресации (по смещению), а второй это связанный список и доступ куда как более медленный, предполагается перебор, в худшем случае (когда нужно найти последний элемент) — придется долго перебирать все до единого элементы. И только доступ к первому-второму элементу сопоставимы по времени с доступом к элементу в массиве.
Второй вопрос:
Ну дык это же от размера файла зависит. Если он целиком помещается в оперативку, то это всего-то «открыть, прочитать, сортировать, записать» с использованием какой-то библиотечной функции.
А вот если размер файла может быть непредсказуемо огромным и программа должна это уметь — это весьма и весьма непростая задача. Уж всяко несопоставимая с первой трактовкой этой задачи. И далеко не всякий отличник учебы, сдавший всего Кнута на 5, сможет сходу решить ее.
Про рекурсию просто. Но, согласен, что это хороший тест. Рекурсию многие даже «настоящие программисты» не понимют.
Более того, на заре программирования (лет 50 назад) её даже опытные люди (профессора и т.п.) хотели запретить при проектировании какого-то языка программирования (то ли Алголя, то ли еще какого из тех времен).
И далеко не всякий отличник учебы, сдавший всего Кнута на 5, сможет сходу решить ее.
Это вообще как? У Кнута она же разбиралась...
Гм.
Вам нужно попросить родственников найти и держать под рукой телефон псих. больницы — ибо вы на грани.
Я знаю, где искать решение этой задачи (например, как раз у Кнута).
Но я не помню как её решать.
И, кстати, вполне возможно, мне проще будет самому придумать решение, а не разбираться с тем, что написано у Кнута.
Но знать их на память, если ты этим не занимаешься в повседневной деятельности — совсем не надо.
Достаточно знать где искать.
Да и, опытному программисту придумать такие вещи тоже не очень-то и сложно.
Но для студентов и джунов, да, эти вещи — большие откровения.
Да и, опытному программисту придумать такие вещи тоже не очень-то и сложно.
Так в том-то и дело! Достаточно знать как такие алгоритмы придумываются — и второй вопрос не будет представлять сложности даже на больших размерах файлов.
Далеко не во всяком. И даже не в каждом сотом проекте, но — да.
И вот потому что это нужно даже не в каждом сотом проекте, то для собеседования по приему на работу, если вы не MS и не Google — как то слишком.
Тестить следует общие познания (я так и делаю, когда провожу собеседования), общий кругозор.
А вовсе не такие хитрые и специфические мало кому нужные алгоритмы проверять как внешняя сортировка.
Если интересно мое мнение, опыта у вас много, но читаете по профессии недостаточно)
При оценке быстродействия структур данных положено различать разные операции над ними и использовать o-нотацию. big data, map-reduce, сортировка в кластере, наверное, знакомы всем, кто активно интересуется современным IT. Самый простой способ решить такую задачу — сортировка слиянием (merge sort). Имхо, каждый уважающий себя программист должен прочитать хотя бы одну книжку по алгоритмам. Мне нравится вот эта: http://www.ozon.ru/context/detail/id/6290126/
Конечно, нельзя требовать знание всего этого с джуна… но кто сказал, что эти вопросы годятся только для него?)
Но не думаю, что знание этих самых «о» реально должно быть важно при приеме на работу.
Если человек не знает О-нотации — значит, он не умеет оценивать сложность алгоритмов. А значит, он будет "плавать" в тех задачах, где важна оптимизация.
Когда вы проводили последний раз анализ какой-либо библиотеки на предмет использования в своем проекте и вам нужно было о()
Вчера. Вот буквально вчера писал код и думал: "тут для простоты я использую квадратичный алгоритм — значит, надо убедиться, что большие наборы данных сюда не попадут".
"тут для простоты я использую квадратичный алгоритм — значит, надо убедиться, что большие наборы данных сюда не попадут"
Шикарный пример оптимизации xD
А если серьёзно, то проблема действительно есть… мало программистов задумываются о производительности своего кода, хотя в большинстве случаев это упирается в незнание SQL. Ну и да, иногда попадаются на ревью квадратичные алгоритмы там, где можно было бы обойтись линейным, но это гораздо реже.
мало программистов задумываются о производительности своего кода
Реальные оценки — они на совсем других, более банальных, уровнях:
- Минимизируй использование диска/сети, эффективнее используй оперативную память.
- Максимизируй получение/передачу данных за один приём.
И это собственно, все, что нужно знать, чтобы в типовых случаях поднять производительность программы процентов на 80%.
«Квадратичные» алгоритмы и т.п. — занимаются оставшимися 20% производительности.
В реальном бизнесе до этой оптимизации дело редко когда доходит, потому как в нынешние времена время программистов дорого, а при том что железо дешево.
«Квадратичные» алгоритмы и т.п. — занимаются оставшимися 20% производительности.
Но что будет делать ничего не знающий программист, когда алгоритмически сложная задача внезапно возникнет перед ним? Просто возьмет и напишет нужный алгоритм (или авторитетно скажет что это невозможно и надо искать альтернативный путь) — или будет в панике задавать на ru.SO дурацкие вопросы?
Реальные оценки — они на совсем других, более банальных, уровнях:
- Минимизируй использование диска/сети, эффективнее используй оперативную память.
- Максимизируй получение/передачу данных за один приём.
То есть для этих задач теория ну вот совсем не нужна?
Реальные оценки — они на совсем других, более банальных, уровнях:
Минимизируй использование диска/сети, эффективнее используй оперативную память.
Максимизируй получение/передачу данных за один приём
Ответ на цитату:
То есть для этих задач теория ну вот совсем не нужна?
Мне вас очень жаль, если до столь очевидных вещей вам нужно доходить только после 4-5 лет теории в ВУЗЕ.
Это вполне можно поставить фактом и заставить зубрить на третьем месяце обучения программированию.
Безо всякой теории.
Но что будет делать ничего не знающий программист, когда алгоритмически сложная задача внезапно возникнет перед ним?
Вы взаправду считаете, что вот так много лет можно щи хлебать лаптем (не заниматься ничем подобным), а потом — бац — вас приглашают во дворец фирмы Google (возникает прямо-таки сложная задача и вы первый кому её поручают после долгих лет отсутствия у вас подходящего под эту задачу опыта)?
95% программеров никогда в жизни не будут заниматься ничем подобным даже рядом.
Никогда не будут.
Это отнюдь не повод их все учить в ВУЗах — проедать государственные деньги, деньги своих родителей, позднее нанинать работать (что вредно для ВВП)…
Подавляющему большинство вполне хватит на всю жизнь и техникумов и ПТУ.
А оставшиеся 5% — да, вполне могут заниматься программированием на совсем других уровнях.
Но их всего лишь 5%…
Уверяю вас:
Никакая теория из 2-х моих высших образований (профильных) ни разу мне не пригодились за 20 лет программирования.
Только общий кругозор.
Как-то вы хитро перешли от азов оценки сложности алгоритмов к ВУЗам и ПТУ.
А хитрая задача — она где угодно возникнуть может. Случайно.
PS
Это вполне можно поставить фактом и заставить зубрить на третьем месяце обучения программированию.
Поставить фактом — что? Как вообще можно ставить задачу максимизации или минимизации, не дав средство оценки максимизируемой или минимизируемой величины?
А хитрая задача — она где угодно возникнуть может. Случайно.
Если вы когда-то умели решать сложные вычислительные задачи, но при этом целыми днями и годами делаете сайтики да рисуете интерфейсы в Андроиде, то вы деградируете в области решения сложных вычислительных задач, но при этом отлично затачивайтесь на интерфейсики.
Нет никакого рационального смысла 4-5 лет учиться, чтобы потом перетачивать свое мышление с вычислительных задач на другие.
Неожиданно такие задачи не возникают.
И все равно эти задачи поставят вас в тупик — ваш заточенный на интерфейсики мозг будет их решать долго.
Да, вы что-то вспомните, где-то почитаете и, долго-долго, но решите.
Но зачем тратить лишние годы в ВУЗе, если 99% нужного программисту знания осваивается за 2 года даже с запасом. А еще 2-3 года программист тратите на теорию, которая или вообще никогда не пригодится в его работе никогда или пригодится раз в 10 лет.
Поставить фактом — что? Как вообще можно ставить задачу максимизации или минимизации, не дав средство оценки максимизируемой или минимизируемой величины?
Если вы джун или студент — то еще понятно ваше непонимание.
Но если вы хотя бы миддл…
То вы очень слабый программер, если вам не очевидны эти правила:
Реальные оценки — они на совсем других, более банальных, уровнях:
- Минимизируй использование диска/сети, эффективнее используй оперативную память.
- Максимизируй получение/передачу данных за один приём
Поставить фактом — что? Как вообще можно ставить задачу максимизации или минимизации, не дав средство оценки максимизируемой или минимизируемой величины?
Программирование — это не математическая функция с известным графиком. Когда можно предсказать точно — здесь приложишь столько-то усилий — получишь такой то выхлоп. Точно.
Все не так.
В программировании, если конечно речь не идет о бесконечном финансировании — большое значение имеет финансовая рациональность.
Поэтому задача частенько ставится не
«оптимизировать, чтобы отклик был не более 10 us»,
а по военной системе:
«копать отсюда и до обеда»,
другими словами — «вот ограниченный бюджет, что лучшее мы можем выжать из этого бюджета».
другими словами — бюджет (время, деньги) закончился — завершай и оптимизацию. До скольки удалось сделать — смотрим. Удается получить дополнительное время/деньги — продолжаем оптимизацию.
Не удается — останавливаемся на этом этапе.
Как правило в 95% случаев дополнительные бюджеты времени и денег на слишком глубокую оптимизацию не выделяют.
Поэтому вполне достаточно следования сразу при проектировании системы основным принципам.
То, о чем пишете вы — это уже ближе к переоптимизации и на ранних этапах не рекомендуется.
А то вы прототип/альфу будете выкатывать неоправдано долго.
Как-то вы хитро перешли от азов оценки сложности алгоритмов к ВУЗам и ПТУ.
А хитрая задача — она где угодно возникнуть может. Случайно.
Я отнюдь не отрицаю полезность знаний как таковых.
Я отрицаю необходимость обязательного получения глубоких теоретических знаний, чтобы работать успешным программистом.
Вы бы еще написали — защитивший диссертацию на кандидата технических наук будет более крутым программистом.
Нет. Он будет, скорее всего, средним программистом, а то и джуном (видел таких кандидатов технических наук в большом числе), за исключением своей очень узкой области.
Глубокие теоретически знания вам не нужны, чтобы принимать решения в области программирования на практике.
20 лет опыта программирования мне говорят об этом.
P.S.:
Профильное образование имею.
Не пригодилось.
Пригодился только общий кругозор,
уверенность в своих силах, которые дает ВУЗ.
Не припомню ситуаций, где мне прям кровь из носу
нужно было точно знать что именно здесь: o(n) или о(n^2).
Вполне достаточно понимания — как сделать быстрее.
Глубокой теории для этого не нужно. Выбор путей решения в реальном мире не столь велик.
Если у вас после 4-7 лет опыта не будет чутья чтобы без о() сразу видеть лучший путь — вы выбрали явно не ту профессию.
Да где вы вообще увидели глубокие теоретические знания-то?
А математика, физика, о()?
Какая о(), когда программист по десять раз на дню принимает решения куда двигать написание программы и непрерывно оценивает свой алгоритм.
Оценка основанная на здравом смысле и опыте — имеет преимущество перед академическими знаниями.
тут для простоты я использую квадратичный алгоритм — значит, надо убедиться, что большие наборы данных сюда не попадут
Вах. Круто. Чувствуется свежезакончивший (или еще учащийся; в крайнем случае, думаю, не более как 5 лет назад закончивший).
Я такие вещи безо всяких квадратичных слов оцениваю.
Давным-давно все уже отлично работает на уровне интуиции.
;)
тут для простоты я использую квадратичный алгоритм — значит, надо убедиться, что большие наборы данных сюда не попадут
Это абсолютно нормально если вы джун или студент.
Если вы миддл, еще туда-сюда…
Хотя, имхо, для мидлла такой уровень детализации при принятии решений — это уже избыточно.
Если вы сеньор и продолжаете думать в тех же терминах
Гм…
Вы выбрали не ту профессию.
А в каких терминах должен думать сеньор? :)
Когда ты проговариваешь про себя формулировки — это слабое знание.
Это как с иностранным языком, например. Пока слабо знаешь — заранее произносишь фразы мысленно, заранее их составляешь.
Когда язык уже освоен — иноземная речь из тебя льется без какого-либо напряжения, без особого мыслительного усилия.
А с чего вы взяли, что я эту мысль проговаривал?
Интуиция — полезная вещь, но на пустом месте она не возникает. Чтобы интуитивно чувствовать "медленные" места в алгоритме — надо знать чем медленное место отличается от быстрого. Без нужных знаний никакая интуиция не поможет.
Между мной и вами разница — что я вообще не мыслю уже этими категориями: квадратичное или какое.
Я просто знаю
Сразу.
Не думаю, что какая-то теория о о() мне в этом помогает.
Только опыт.
В том числе — и для новых технологий знания срабатывают.
Узкие места — на которые нужно обращать внимание — они и в новых технологиях остаются теми же — диск, сеть.
Какая разница, мыслите вы этими категориями или нет — если вы их тоже знаете? Нельзя так сразу взять и начать "просто знать". Вы не смогли бы приобрести опыт оптимизации программ если бы никогда не читали и не слушали про методы оценки времени работы алгоритмов.
А еще "просто знание" и интуиция очень плохо передаются по каналам связи.
Поэтому от академических оценок о() толка на практике очень мало.
Вполне достаточно здравого смысла и опыта.
А учитывая как обширно современное ИТ — лучше тратить время не на математику и физику и о() — это все пригодится только процентам программистов-выпускников учебных заведений, а — архитектуры и СУБД, учиться делать замеры производительности и т.п. практические вещи, а не академические знания, которые хороши только для формального доказывания эффективности алгоритмов.
https://habrahabr.ru/company/mailru/blog/316740/
Нам понадобилось уменьшить количество закупаемого железа и цену за хостинг. Чтобы найти, где сэкономить, давайте посмотрим, из чего состоит почта.
Индексы и тела писем составляют 15 % объёма, файлы — 85 %. Место для оптимизаций надо искать в файлах (аттачах в письмах). На тот момент у нас не была реализована дедупликация файлов; по нашим оценкам, она может дать экономию в 36 % всего объёма почты: многим пользователям приходят одинаковые письма (рассылки социальных сетей с картинками, магазинов с прайсами и т.д.). В этом посте я расскажу про реализацию такой системы, сделанной под руководством PSIAlt.
Хранилище метаинформации
Есть поток файлов, и надо быстро понимать, дублируется файл или нет. Простое решение — давать им имена, которые генерируются на основе содержимого файла. Мы используем sha1. Изначальное имя файла хранится в самом письме, поэтому о нём заботиться не надо.
Мы получили письмо, достали файлы, посчитали от содержимого sha1 и значение вычисления добавили в письмо. Это необходимо, чтобы при отдаче письма легко найти его файлы в нашем будущем хранилище.
И так далее.
Какую долю в размышлениях занимает самый обычный здравый смысл (98% или 99,9%)?
А какую долю занимают оценки по о() или тому подобная, что требует специальной теоретической подготовки, выходящей за пределы обычного здравого смысла?
В нашей личной жизни, мы намеренно умалчиваем о нашем образовании в лагере программистов.
Я всегда думал, что «личная жизнь» — это немного другое.
PS. Запятая после «жизни» лишняя.
В противном случае, нас автоматически классифицируют как младших разработчиков или как работников, у которых недостаточно опыта.
Я посвящал целые дни изучению алгоритмов сортировки
Я не понял из статьи — осознает ли автор, что он по квалификации находится максимум на уровне джуна (если я правильно понимаю, то за плечами у него только этот «летний лагерь»)?
Если да — то непонятно, зачем вся эта возня на три месяца: проработать месяц и быть уволенным из-за недостаточной квалификации?
Замечательный лагерь, я считаю. Делает миддлов с нуля всего за три месяца.
Я провел 3 месяца, пытаясь устроиться на работу после лагеря программирования, и вот чему я научился