Если собственнику все это нужно, то он находит такую сумму и вносит залог (не оплату, а именно залог). Как только внутренние проблемы фирмы разрулятся, счет будет оплачен, а залог возвращен владельцу.
Деталей для оценки ситуации не достаточно.
Но представьте себе ситуацию, когда фирма банкротится и открывается новая которой передаются права на сайт. Провайдеру долг взыскивать не с кого.
Если у провайдера есть оборудование клиента, тогда другое дело — его как раз и можно предоставить в залог, однако, как я понял это собственность фирмы и учредитель не может имуществом распоряжаться в обход директора.
Учитывая UPD от провайдера и собственника, проголосовал за провайдера, а собственнику можно посочувствовать.
Согласен, ради конкретно такого примера не стоило бы.
В моей задаче строчек для вставки в словарь сильно больше (30+), вдобавок, есть внутренняя логика if/else.
Создание промежуточных переменных не добавляет читаемости.
Я не настаиваю, что мой код абсолютно более читаемый, но найдутся те, кто со мной согласятся.
Равно как найдутся те, кто скажет, что это отстой — и последних в 4 раза больше :)
Т.к. автор может изменить формулировку условия в посте, привожу то, которое досталось мне на момент прочтения:
Вероятность того, что в один из двенадцати стульев зашиты бриллианты, равна 0.9. При предположении, что стулья вскрывают поочерёдно, причём к следующему переходят только в том случае, если в текущем стуле не нашлось бриллиантов, найти вероятность того, что бриллианты окажутся в 12 по счёту стуле.
Т.к. мы не рассматриваем вероятность того, дойдем ли мы до 12-го стула или нет, то по условию задачи нужно посчитать вероятность того, что бриллианты в 12-м стуле — это означает (по условию задачи: «мы переходим к следующему стулу, если в предыдущем бриллиантов нет»), что во всех предыдущих 11 стульях бриллиантов не было.
Т.к. у нас всего 12 стульев (других больше нет), а вероятность того, что хоть в каком-то из них — 0.9. Получается, вероятность — 0.9.
Такую задачку можно задавать на собеседовании на проверку внимательности и логики рассуждений.
Жаль, что автор сам ошибся (либо в постановке задачи либо в ее решении).
Если принять эту формулу за истину, то выходит, что IQ нужно обязательно тестировать, т.к. его прокачать нельзя :)
А раз EQ можно прокачать, то сгодится кандидат со средним EQ, но с потенциалом роста этого EQ ;-)
Однако, я не считаю, что отсутствие экзамена на собеседовании это хорошо.
Безусловно, без разговора с кандидатом по вопросам, приведенным в статье, собеседование будет однобоким.
Есть высокий риск взять не того человека. Но текущий уровень знаний (или опыт) все же сильно влияет на начальный
уровень компенсации. Наличие «олимпиадных» задачек, позволяет проверить IQ кандидата.
Да, 50% успеха в работе зависит от EQ, но вторые-то 50% от IQ!!! ;-)
Беседа «за жизнь» обязательна, кандидат прежде всего должен хотеть работать.
И на собеседовании нам нужно понять хотим ли мы с ним работать, как с человеком.
Второе — проверка знаний и соображалки, которая позволяет вычислить размер компенсации и наших ожиданий.
Я на собеседовании всегда предлагаю решить тестовые задачи. Причем, кандидаты сначала решают их, а потом мы общаемся.
Начинаем с обсуждения решений. Если по задачам все тухло, то общение «за жизнь» укорачивается.
P.S. Был один кандидат (из полутора сотен), который отказался решать задачи. Но я не жалею — я не потратил время.
Сама его «несговорчивость» говорит против него — в работе он тоже от чего-то отказался бы, посчитав зазорным.
Зачем компании такой привередливый сотрудник? Да, я уважаю его позицию, он может быть владельцем или руководителем
компании, а сотрудники такие не нужны.
Если кратко, то из всего сказанного не следует, что концепция FRP проще для работы большими системами.
В свое время все восторгались Prolog'ом, но и где же он?
Также обезумевали от XML'я (XML-RPC), но он занял свое ограниченное место.
Тем временим те самые «бородатые мужики», как писали на C, так и продолжают это делать ;-)
Воодушевленный просмотром твоего доклада посмотрел еще про FRP (http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey)
Дольше и менее весело, но не менее познавательно :) (или даже более).
Если я правильно уловил ключевую мысль FRP, это то, что «ВСЕ» что мы считаем индикаторами состояний меняется постоянно и параллельно. Также, как это происходило бы в реальном мире вокруг нас. Каждый индикатор представлен не своим «значением состояния на сейчас», а виде последовательности значений зафиксированных в каких-то моментах времени. Т.е. всегда, когда мы подсматриваем значение чего-то, это значение на момент начала подглядывания, а к концу подглядывания, значение уже может быть другим, но мы не узнаем если не начнем подглядывать снова (да нам и не надо...). Есть «микро-программки» — они же обсерверы — которые умеют наблюдать «прошлое» и инициировать перевод индикаторов из состояния в состояние посредством «чистой функции», которая не ничего не знает про индикаторы (это самая примитивная машина тьюринга «текущее значение индикатора»+«сивол»->«новое значени индикатора», у тьюринга был еще сайд-эффект — напечатать что-то, которого тут нет :)).
Так к чему я все это. В этой парадигме ничто не мешает делать циклические зависимости. Даже Excel это позволяет делать (через настройки надо только задать количество итераций и/или погрешность, когда можно прекратить считать, полагая, что все ячейки устаканились).
Если пойди дальше, и сформулировать отношения (зависимости) в виде дифференциальных уравнений, то мы еще ближе приближаемся к реальному миру. Визуализацию можно представить на этой картинке: audiomap.tuneglue.net/ (поискать любое слово — потом потыкать и подергать за кружочки — остальные тянутся сами балансируя как-то между собой). То же самое можно отнести и к индикаторам, которые «подтягиваются» к изменившимся значениям других индикаторов. И все это работает параллельно. Т.е. ни у кого нет возможности зафиксировать «все состояние» — оно меняется непрерывно и мы принимая решения опираемся всегда на устаревшие данные.
Боюсь сложно уследить за моим потоком сознания, тем не менее, а причем здесь Павел Кудинов?
Так вот он и говорит (то что я для себя услышал): вычислительные мощности растут и мы можем позволить себе писать программы «а бы как», не увлекаясь исправлением всех ошибок. Ошибки были, есть и будут всегда — это данность, которую надо принять. Гораздо важнее писать код так, чтобы он мог работать с кривыми данными и выдавать приемлемый результат, т.е. чтобы уровень ущерба от ошибок был ниже полезности системы. В cloujure в сам подход закладывается, что она работает с неактуальными данными — ВСЕГДА. Т.е. результат ее работы приблизительный, но нам больше и не нужно. Что-то поменяется, ну и система автоматом поменяет…
Скажем так, аналогия здесь не проглядывается, но просто подход clojure и подход Павла дополняют друг друга.
Я не считаю (пока?) что и то (FRP) и другое (Костыли — это кошерно) — это правильно и надо именно этим пользоваться / так делать :)
Про весь frp не скажу (не знаю), но судя по докладу, если нам важен порядок, то это уже не Frp.
А вот интересуюет поддержка циклов и интерференции.
Циклы: a->b->c->a
Интерференция: a->b->d, a->c->d
Вообще говоря, у меня сильные сомнения на счет closure — это наше все. Хотя если взглянуть на устройство природы вокруг нас (и вспомнить не менее фееричный доклад Павла Кудинова в 2010-м году), то можно утверждать, что все вокруг нас и есть одно большое closure :)
Но! Накладные расходы на презентацию пользователю глобального состояния, через машину тьюринга очень велики. (Последнее предложение получилось, как тут habrahabr.ru/post/193950/#comment_6735204) :)
роботы могут работать круглосуточно: 24x7 вместо 8x5 (+20 выходных в год + больничные), т.е. производительность роботов больше чем в 4 раза выше. Не знаю сколько получают австралийские водители, но допустим $4000/месяц (каждый месяц, каждый год)
Разработка системы в основном единоразовые затраты.
Вот и прикинуть можно 10 самосвалов по $4000 * 4 * 12 месяцев на 10 лет = $19,2 млн
Не знаю сколько может стоить разработка системы управления роботами, но их эксплуатация в разы дешевле $4k/месяц, и потом они не жалуются, не увольняются и пр. :)
Детская загадка:
Что находится посредине Земли?
Ответ: буква «М».
Это пример, когда путают объект с частью языка – словом
… и только потом догадался, какое отношение буква «м» имеет к центру Земли…
В качестве развлечения статья неплохая и даже веселая, но практическая польза нулевая :)
P.S. кстати ни у кого нет ссылки на видео, где на одной из конференций кто-то утверждал почему нет
необходимости исправлять ошибки в коде? Там были приведены отличные формулы.
Давайте вернемся к правилам русского языка (по крайней мере тем, что я учил в школе):
Местоимения Вы и Ваш пишутся с прописной (большой) буквы при обращении к одному лицу;
при обращении к нескольким лицам следует писать вы и ваш со строчной буквы.
Т.к. текст сайта читает конкретный человек, и если в тексте идет обращение именно к нему, то должно быть «Вы».
Если вы (я имею ввиду группу несогласных со мной) хотите быть грамотным, то в обращениях к кому-то конкретному пишете «Вы» — никаких заискиваний — просто грамотное письмо.
С идей автора согласен, что тексты могут убить картинки, но с тезисами (почти со всеми) готов поспорить.
Было бы неплохо, если бы вы скинули сюда список литературы, где показано как правильно писать тексты,
типа вот этого (О Гилви): www.adv2adv.ru/training_courses/copywriting/useful_articles/d_ogilvi/
Деталей для оценки ситуации не достаточно.
Но представьте себе ситуацию, когда фирма банкротится и открывается новая которой передаются права на сайт. Провайдеру долг взыскивать не с кого.
Если у провайдера есть оборудование клиента, тогда другое дело — его как раз и можно предоставить в залог, однако, как я понял это собственность фирмы и учредитель не может имуществом распоряжаться в обход директора.
Учитывая UPD от провайдера и собственника, проголосовал за провайдера, а собственнику можно посочувствовать.
И дали ссылку на более продвинутую реализацию моего подхода: addict
В моей задаче строчек для вставки в словарь сильно больше (30+), вдобавок, есть внутренняя логика if/else.
Создание промежуточных переменных не добавляет читаемости.
Я не настаиваю, что мой код абсолютно более читаемый, но найдутся те, кто со мной согласятся.
Равно как найдутся те, кто скажет, что это отстой — и последних в 4 раза больше :)
Просто мне показалось, что вот так писать — это не по-питоновски:
Хотелось вот так:
P.S. {}.get('key',None) — не то делает, что мне нужно.
The_Freeman правильно написал. Попробую перефразировать:
Т.к. мы не рассматриваем вероятность того, дойдем ли мы до 12-го стула или нет, то по условию задачи нужно посчитать вероятность того, что бриллианты в 12-м стуле — это означает (по условию задачи: «мы переходим к следующему стулу, если в предыдущем бриллиантов нет»), что во всех предыдущих 11 стульях бриллиантов не было.
Т.к. у нас всего 12 стульев (других больше нет), а вероятность того, что хоть в каком-то из них — 0.9. Получается, вероятность — 0.9.
Такую задачку можно задавать на собеседовании на проверку внимательности и логики рассуждений.
Жаль, что автор сам ошибся (либо в постановке задачи либо в ее решении).
Какое количество транзакций/запросов в сутки?
Прошло почти 1,5 года — были ли сбои? Если да — расскажите о них и как решали.
А раз EQ можно прокачать, то сгодится кандидат со средним EQ, но с потенциалом роста этого EQ ;-)
Однако, я не считаю, что отсутствие экзамена на собеседовании это хорошо.
Безусловно, без разговора с кандидатом по вопросам, приведенным в статье, собеседование будет однобоким.
Есть высокий риск взять не того человека. Но текущий уровень знаний (или опыт) все же сильно влияет на начальный
уровень компенсации. Наличие «олимпиадных» задачек, позволяет проверить IQ кандидата.
Да, 50% успеха в работе зависит от EQ, но вторые-то 50% от IQ!!! ;-)
Беседа «за жизнь» обязательна, кандидат прежде всего должен хотеть работать.
И на собеседовании нам нужно понять хотим ли мы с ним работать, как с человеком.
Второе — проверка знаний и соображалки, которая позволяет вычислить размер компенсации и наших ожиданий.
Я на собеседовании всегда предлагаю решить тестовые задачи. Причем, кандидаты сначала решают их, а потом мы общаемся.
Начинаем с обсуждения решений. Если по задачам все тухло, то общение «за жизнь» укорачивается.
P.S. Был один кандидат (из полутора сотен), который отказался решать задачи. Но я не жалею — я не потратил время.
Сама его «несговорчивость» говорит против него — в работе он тоже от чего-то отказался бы, посчитав зазорным.
Зачем компании такой привередливый сотрудник? Да, я уважаю его позицию, он может быть владельцем или руководителем
компании, а сотрудники такие не нужны.
В свое время все восторгались Prolog'ом, но и где же он?
Также обезумевали от XML'я (XML-RPC), но он занял свое ограниченное место.
Тем временим те самые «бородатые мужики», как писали на C, так и продолжают это делать ;-)
Clojure, больше подходит для программирования на вот таких штуках: ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%BE%D0%B3%D0%BE%D0%B2%D1%8B%D0%B9_%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80
Дольше и менее весело, но не менее познавательно :) (или даже более).
Если я правильно уловил ключевую мысль FRP, это то, что «ВСЕ» что мы считаем индикаторами состояний меняется постоянно и параллельно. Также, как это происходило бы в реальном мире вокруг нас. Каждый индикатор представлен не своим «значением состояния на сейчас», а виде последовательности значений зафиксированных в каких-то моментах времени. Т.е. всегда, когда мы подсматриваем значение чего-то, это значение на момент начала подглядывания, а к концу подглядывания, значение уже может быть другим, но мы не узнаем если не начнем подглядывать снова (да нам и не надо...). Есть «микро-программки» — они же обсерверы — которые умеют наблюдать «прошлое» и инициировать перевод индикаторов из состояния в состояние посредством «чистой функции», которая не ничего не знает про индикаторы (это самая примитивная машина тьюринга «текущее значение индикатора»+«сивол»->«новое значени индикатора», у тьюринга был еще сайд-эффект — напечатать что-то, которого тут нет :)).
Так к чему я все это. В этой парадигме ничто не мешает делать циклические зависимости. Даже Excel это позволяет делать (через настройки надо только задать количество итераций и/или погрешность, когда можно прекратить считать, полагая, что все ячейки устаканились).
Если пойди дальше, и сформулировать отношения (зависимости) в виде дифференциальных уравнений, то мы еще ближе приближаемся к реальному миру. Визуализацию можно представить на этой картинке: audiomap.tuneglue.net/ (поискать любое слово — потом потыкать и подергать за кружочки — остальные тянутся сами балансируя как-то между собой). То же самое можно отнести и к индикаторам, которые «подтягиваются» к изменившимся значениям других индикаторов. И все это работает параллельно. Т.е. ни у кого нет возможности зафиксировать «все состояние» — оно меняется непрерывно и мы принимая решения опираемся всегда на устаревшие данные.
Боюсь сложно уследить за моим потоком сознания, тем не менее, а причем здесь Павел Кудинов?
Так вот он и говорит (то что я для себя услышал): вычислительные мощности растут и мы можем позволить себе писать программы «а бы как», не увлекаясь исправлением всех ошибок. Ошибки были, есть и будут всегда — это данность, которую надо принять. Гораздо важнее писать код так, чтобы он мог работать с кривыми данными и выдавать приемлемый результат, т.е. чтобы уровень ущерба от ошибок был ниже полезности системы. В cloujure в сам подход закладывается, что она работает с неактуальными данными — ВСЕГДА. Т.е. результат ее работы приблизительный, но нам больше и не нужно. Что-то поменяется, ну и система автоматом поменяет…
Скажем так, аналогия здесь не проглядывается, но просто подход clojure и подход Павла дополняют друг друга.
Я не считаю (пока?) что и то (FRP) и другое (Костыли — это кошерно) — это правильно и надо именно этим пользоваться / так делать :)
И спасибо за доклад! (FRP'ом в мозг)
А вот интересуюет поддержка циклов и интерференции.
Циклы: a->b->c->a
Интерференция: a->b->d, a->c->d
Вообще говоря, у меня сильные сомнения на счет closure — это наше все. Хотя если взглянуть на устройство природы вокруг нас (и вспомнить не менее фееричный доклад Павла Кудинова в 2010-м году), то можно утверждать, что все вокруг нас и есть одно большое closure :)
Но! Накладные расходы на презентацию пользователю глобального состояния, через машину тьюринга очень велики. (Последнее предложение получилось, как тут habrahabr.ru/post/193950/#comment_6735204) :)
Что там не так?
Разработка системы в основном единоразовые затраты.
Вот и прикинуть можно 10 самосвалов по $4000 * 4 * 12 месяцев на 10 лет = $19,2 млн
Не знаю сколько может стоить разработка системы управления роботами, но их эксплуатация в разы дешевле $4k/месяц, и потом они не жалуются, не увольняются и пр. :)
этот доклад должен послушать каждый программист! :)
Спасибо огромное!
А вот тут подвис секунд на 15-20, «где подвох?»…
… и только потом догадался, какое отношение буква «м» имеет к центру Земли…
В качестве развлечения статья неплохая и даже веселая, но практическая польза нулевая :)
P.S. кстати ни у кого нет ссылки на видео, где на одной из конференций кто-то утверждал почему нет
необходимости исправлять ошибки в коде? Там были приведены отличные формулы.
Местоимения Вы и Ваш пишутся с прописной (большой) буквы при обращении к одному лицу;
при обращении к нескольким лицам следует писать вы и ваш со строчной буквы.
www.gramota.ru/spravka/letters/?rub=rubric_88
Т.к. текст сайта читает конкретный человек, и если в тексте идет обращение именно к нему, то должно быть «Вы».
Если вы (я имею ввиду группу несогласных со мной) хотите быть грамотным, то в обращениях к кому-то конкретному пишете «Вы» — никаких заискиваний — просто грамотное письмо.
С идей автора согласен, что тексты могут убить картинки, но с тезисами (почти со всеми) готов поспорить.
Было бы неплохо, если бы вы скинули сюда список литературы, где показано как правильно писать тексты,
типа вот этого (О Гилви):
www.adv2adv.ru/training_courses/copywriting/useful_articles/d_ogilvi/
Мне также показалось, что сравнение с C/C++ будет интересным, да и на Mac у меня нет C#, чтобы проверить :)