Покер — игра математическая, интересная и захватывающая. Онлайн покер, к сожалению, игра, основанная на информации совершенно не в том контексте, в котором изначально должна быть. Нотсы и ридсы превращаются в ежедневно покупаемые апдейты логов игр (истории) на игроков, собранных ботами (преимущественно), благодаря чему профессиональный (от слова профессия, человек, который зарабатывает на жизнь) игрок в состоянии просто подсесть за стол и раздеть опоннента, на которого у него есть история. 10, 50, 100$ за вечер (micro limits) — так и живут.
Но как в любой игре на деньги, нужно знать, когда вовремя уйти. Когда то играл, сумел уйти (доказав самому себе, что зависимость штука надуманная). Ушел, еще и кэшаут сделал. Назад в онлайн не тянет (слишком уж там неравномерно все получается), живой покер намного интереснее. А уж если играешь с опытными игроками…
Резона нет продаваться, разве есть видимая угроза конкуренции? Twitter уникален по природе своей.
Когда опасно станет аль прижмет кто, так и продадут (Twitter как кость в зубе для Facebook/Google, для Microsoft же скорее способ получить конкретный буст на рынке соц.сетей). Миллиардов за 15, цена вопроса.
А купить за такую сумму, сможет разве что Google Inc.
… который проводил какой-то сомнительный странный эксперимент, профита которого по истечении 10 минут я так и не дождался?
А вот и ответ (оригинал «детального анализа кейса»):
Тогда я предложил главному моему помощнику в этом мероприятии дать некоторую сумму денег в качестве благодарности. Как результат, малой собрал ровно 0 гривень, 0 копеек. Что его расстроило, но дало понять ему, мне и всем участникам панели, что подавляющее большинство людей нифига не ценят то, что их чему-то учат.
>Тут пример приведу — эта функция может использоваться для редактирования настроек форума на сайте. На большом сайте есть маленький форум, у которого есть отдельный админ.
А еще эта функция может предназначаться для конфигурации космического корабля. Эти шведские программисты — они такие хитрецы!
З.Ы простите, мне кажется у вас паранойя, эвалофобия и пробелы в знании предметной области
eval() returns NULL unless return is called in the evaluated code, in which case the value passed to return is returned. If there is a parse error in the evaluated code, eval() returns FALSE and execution of the following code continues normally. It is not possible to catch a parse error in eval() using set_error_handler().
> Да нивапрос. Вас попроси сделать вывод ности из базы — вы, наверное, напишете
А вот тут уже флейм пошел (и причем здесь новости?). Простите, ухожу, не хочу
Поскольку дополнительных требований выдвинуто не было, определение валидности входных данных лягло на плечи разработчика непосредственно. Давайте понимать, что в структуре INI-файла, квадратные скобки (обычно) означают секцию.
Поскольку общепринятого стандарта описания INI-файла нет — то разработчик вполне вправе предпологать, что исходные данные по задаче — максимальны по содержанию и требованию. Все остальное — защита «от дурака» (описано чуть ниже, в другом комментарии).
ИМХО не стоит усложнять требования задачи самостоятельно. Оставьте это постановщикам той самой задачи. Задача же программиста — перенести бизнес-логику в код, описав ее и только ее максимально просто и понятно и обработав только те исключения, которые предпологаются контекстом задачи
Никакой шутки — никакого смайла
З.Ы для защиты от «запрещенных» символов — достаточно всего навсего дописать экранирование ключа. Но опять же, это выходит за рамки конкретной задачи. Если собеседующие люди укажут на те факторы, которые вы описали выше — они будут безусловно правы (заказчик всегда прав?), но это уже будет «change request», так как одна из составляющих бизнес-логики изменилась (формат данных). И это уже будет совершенно другая задача, пусть и связанная.
Вы можете сказать, что можно было подобную задачу решить «наперед», просто подумав об этой возможности? Безусловно можно, любой мало-мальски толковый программист именно так и сделает! Но есть одно НО. Давайте представим, что мы описываем не простейшую функцию, а огромный и сложный кусок бизнес-логики. И добавление неописанных в ТЗ обработчиков поведения — затягивает рабочий процесс, релиз, не на несколько минут, а на дни, недели, месяцы? А потом выясняется, что этот функционал и вовсе не нужен, так как там всегда будет только точка и литералы, и ничего кроме? Понимаете, о чем я? :)
Вот тут вот, в ваших словах, и скрыт глубокий смысл — эти самые убеждения, порой, доходят до абсурда. Программист просто не в состоянии порой объяснить, почему именно это плохо. Это просто — плохо. Плохо и все, так в интернете написано было да и друг, старый программист на Cobol рассказал.
Безусловно, есть минусы. В реальном проекте нужно трижды подумать, прежде чем выбирать путь решения задачи (назад дороги не будет, как правило).
Есть очень хорошая пословица: «Не уверен — не обгоняй». В нашем с вами деле — то же самое :)
Нет смысла ИМХО идти к работодателю, который считает eval вселенским злом. Это либо человек с предрассудками, либо владелец бизнеса с плохой тенденцией к микроменеджменту. Если собеседуемый действительно подкованный человек, он сумеет найти подходящий аргумент и переубедить, почему именно его вариант правильный. Именно таких людей и ищут на senior+ должности — уверенных (но не самоуверенных) :)
Вы ненавидите eval потому, что… кто то сказал, что это плохо? PHP интерпретируемый язык, это все один сплошной eval, нет?
Есть задача. Строгая, типизированная, задача. Поставленная программистами — программисту. Задача содержит в себе глубокий смысл — а именно, возможность понять, как мыслит человек, которых проходит собеседование. И поверьте — мне кажется, что ответ с eval вполне удовлетворил бы этих господ. Почему? Он (ответ) не стандартен, а значит человек который можут думать нестандартно — будет способен решать другие задачи быстро, дешево и изящно. Лично я бы хотел бы видеть как можно больше людей с нестандартным мышлением в своей команде. Почему? Для стандартных решений я умею пользоваться google.
Задача. Черный ящик, со входом и выходом. Давайте попробуем в данные 10 минут решить самое главное требование — реализацию бизнес-логики приложения. А проверки на «присутствует ли физически файл конфига», «не пришел ли барабашка и не положил ли в конфиг беду» и прочие вещи, которые выходят за рамки конкретной задачи — будем решать по мере поступления новых требований, а не заниматься отсебятиной?
Вот потому и имеем (к сожалению) в мире людей, которые занимаются всем чем угодно: красивостями, построением «защиты от дурака», стадным блюдением стандартов — всем, чем угодно, но только не самой задачей в полной мере ее объема до ее логического завершения.
Знаете, в жизни каждого программиста происходит переломный момент, когда выражения вида «вселенское зло», «быдлокод» и пр. начинают вызывать добрую улыбку :) Вселенское зло не есть eval. Вселенское зло есть 30 строк дополнительного (читать избыточного) кода, созданного либо потому, что другого подхода к решению программист не видел (это лечится, приходит с опытом и все будет хорошо), либо же (второй вариант, клинический) — когда программист знает и отдает себе отчет, что это избыточный код, но… в его eval будут тыкать пальцами.
Зло eval'a в параграфе выше преувеличено, на его примере показана практика чтения и поддержки стороннего кода, когда main-программист вместо того, чтобы написать коротко и изящно (при этом читаемо и понятно) — пишет операционную систему. Зло, это когда вместо одной регулярки — имеем 50 строк хлама. Зло — это когда простейшую функцию набиваем таким количеством хлама (может быть и нужного, безусловно, но только не на текущий момент времени), что функция просто не читаема.
Зло — это преждевременная оптимизация велосипеда, который изобретать не нужно, но очень хочется.
В задаче ничего не сказано о том, что конфиг является опасным. Не стоит ИМХО придумывать самому себе задачи :) Если имеем дело с потенциально опасным конфигом — тогда условие задачи должно быть сформулировано соотвтствующим образом и в код должна быть добавлена логика валидации
Вот как то вот так: function read_conf($filename) {
foreach (parse_ini_file($filename) as $key=>$value) {
$key = vsprintf('$result["%s"] = "%s";', array(
str_replace('.', '"]["', $key),
$value,
));
eval($key);
}
return $result;
}
Ага… Вакансия: требуется яваскрипт-программист для поддержки и доработки крупного проекта (глубокое знание традиционного китайского языка — обязательно)
Но как в любой игре на деньги, нужно знать, когда вовремя уйти. Когда то играл, сумел уйти (доказав самому себе, что зависимость штука надуманная). Ушел, еще и кэшаут сделал. Назад в онлайн не тянет (слишком уж там неравномерно все получается), живой покер намного интереснее. А уж если играешь с опытными игроками…
online.wsj.com/article/SB10001424052748703716904576134543029279426.html
Это вполне себе возможно (и будет), потому как соц.сети в формате facebook теряют популярность.
Ну что-ж, поговорим через год :)
Когда опасно станет аль прижмет кто, так и продадут (Twitter как кость в зубе для Facebook/Google, для Microsoft же скорее способ получить конкретный буст на рынке соц.сетей). Миллиардов за 15, цена вопроса.
А купить за такую сумму, сможет разве что Google Inc.
А вот и ответ (оригинал «детального анализа кейса»):
Так а что вы тогда делаете в этом топике?
З.Ы предположу, что функция eval всегда так работала
А еще эта функция может предназначаться для конфигурации космического корабля. Эти шведские программисты — они такие хитрецы!
З.Ы простите, мне кажется у вас паранойя, эвалофобия и пробелы в знании предметной области
php.net/manual/en/function.eval.php
Return Values
eval() returns NULL unless return is called in the evaluated code, in which case the value passed to return is returned. If there is a parse error in the evaluated code, eval() returns FALSE and execution of the following code continues normally. It is not possible to catch a parse error in eval() using set_error_handler().
А вот тут уже флейм пошел (и причем здесь новости?). Простите, ухожу, не хочу
Поскольку общепринятого стандарта описания INI-файла нет — то разработчик вполне вправе предпологать, что исходные данные по задаче — максимальны по содержанию и требованию. Все остальное — защита «от дурака» (описано чуть ниже, в другом комментарии).
ИМХО не стоит усложнять требования задачи самостоятельно. Оставьте это постановщикам той самой задачи. Задача же программиста — перенести бизнес-логику в код, описав ее и только ее максимально просто и понятно и обработав только те исключения, которые предпологаются контекстом задачи
Никакой шутки — никакого смайла
З.Ы для защиты от «запрещенных» символов — достаточно всего навсего дописать экранирование ключа. Но опять же, это выходит за рамки конкретной задачи. Если собеседующие люди укажут на те факторы, которые вы описали выше — они будут безусловно правы (заказчик всегда прав?), но это уже будет «change request», так как одна из составляющих бизнес-логики изменилась (формат данных). И это уже будет совершенно другая задача, пусть и связанная.
Вы можете сказать, что можно было подобную задачу решить «наперед», просто подумав об этой возможности? Безусловно можно, любой мало-мальски толковый программист именно так и сделает! Но есть одно НО. Давайте представим, что мы описываем не простейшую функцию, а огромный и сложный кусок бизнес-логики. И добавление неописанных в ТЗ обработчиков поведения — затягивает рабочий процесс, релиз, не на несколько минут, а на дни, недели, месяцы? А потом выясняется, что этот функционал и вовсе не нужен, так как там всегда будет только точка и литералы, и ничего кроме? Понимаете, о чем я? :)
Безусловно, есть минусы. В реальном проекте нужно трижды подумать, прежде чем выбирать путь решения задачи (назад дороги не будет, как правило).
Есть очень хорошая пословица: «Не уверен — не обгоняй». В нашем с вами деле — то же самое :)
Есть задача. Строгая, типизированная, задача. Поставленная программистами — программисту. Задача содержит в себе глубокий смысл — а именно, возможность понять, как мыслит человек, которых проходит собеседование. И поверьте — мне кажется, что ответ с eval вполне удовлетворил бы этих господ. Почему? Он (ответ) не стандартен, а значит человек который можут думать нестандартно — будет способен решать другие задачи быстро, дешево и изящно. Лично я бы хотел бы видеть как можно больше людей с нестандартным мышлением в своей команде. Почему? Для стандартных решений я умею пользоваться google.
Задача. Черный ящик, со входом и выходом. Давайте попробуем в данные 10 минут решить самое главное требование — реализацию бизнес-логики приложения. А проверки на «присутствует ли физически файл конфига», «не пришел ли барабашка и не положил ли в конфиг беду» и прочие вещи, которые выходят за рамки конкретной задачи — будем решать по мере поступления новых требований, а не заниматься отсебятиной?
Вот потому и имеем (к сожалению) в мире людей, которые занимаются всем чем угодно: красивостями, построением «защиты от дурака», стадным блюдением стандартов — всем, чем угодно, но только не самой задачей в полной мере ее объема до ее логического завершения.
Знаете, в жизни каждого программиста происходит переломный момент, когда выражения вида «вселенское зло», «быдлокод» и пр. начинают вызывать добрую улыбку :) Вселенское зло не есть eval. Вселенское зло есть 30 строк дополнительного (читать избыточного) кода, созданного либо потому, что другого подхода к решению программист не видел (это лечится, приходит с опытом и все будет хорошо), либо же (второй вариант, клинический) — когда программист знает и отдает себе отчет, что это избыточный код, но… в его eval будут тыкать пальцами.
Зло eval'a в параграфе выше преувеличено, на его примере показана практика чтения и поддержки стороннего кода, когда main-программист вместо того, чтобы написать коротко и изящно (при этом читаемо и понятно) — пишет операционную систему. Зло, это когда вместо одной регулярки — имеем 50 строк хлама. Зло — это когда простейшую функцию набиваем таким количеством хлама (может быть и нужного, безусловно, но только не на текущий момент времени), что функция просто не читаема.
Зло — это преждевременная оптимизация велосипеда, который изобретать не нужно, но очень хочется.
function read_conf($filename) {
foreach (parse_ini_file($filename) as $key=>$value) {
$key = vsprintf('$result["%s"] = "%s";', array(
str_replace('.', '"]["', $key),
$value,
));
eval($key);
}
return $result;
}
Интересная задачка, но больно прикладная ИМХО