Да о чём спор? Должно быть и то и то и OpenID :-)
Сайты, которые не дают зарегистрировать аккаунт с помощью классической пары email+пароль, явно отдают несерьёзностью.
С другой стороны дополнить классический вариант авторизацией через соц.сети мало кому мешает.
Вряд ли для внутренних систем компании, у которой строгий корпоративный стиль подойдут «мультяшные» прототипы. :)
Подойдут. Не знаю почему, видимо тут что-то на уровне психологии, но когда показываешь прототип с конечными шрифтами, то его начинают воспринимать как дизайн, что в корне не правильно и опускает уровень обсуждения до элементов оформления, что на стадии прототипа вообще ни малейшей роли не играет.
пока буду юзать более «строгий» и лично для меня более удобный MockFlow
Шрифт можно заменить на какой угодно, просто переопределите CSS, который я выше указывал.
Хотя по моему опыту ощущение «мультяшности» просто необходимо для прототипов, если вы собираетесь показывать их заказчику.
Вы забываете что большинство зданий возводятся по типовому проекту. Это ближе к установке CMS в одной из базовых комплектаций, чем к разработке ПО. При строительстве здания по уникальному проекту только разработка арх.проекта и то легко займёт пару лет, не говоря уж про само строительство.
А здания, которые стоят веками, составляют ничтожный процент от общего количества построенного за эти века. К тому же практически все они входят в 3 типа: совсем примитивные, совсем аварийные и памятники-архитектуры. Последние не используются по прямому назначению и для их поддержания в адекватном состоянии выделяются огромные бюджеты.
Однако ПО само по себе не изнашивается в отличии от зданий, т.е. срок жизни программного обеспечения ограничен только сроком жизни типа оборудования, на котором его можно запускать. Разумеется это как минимум десятки лет.
Другой вопрос в моральном устаревании, которое появляется из-за изменений требований к ПО, а отнюдь не из-за внутренних проблем в ПО. Так что пример с ПО для спутников вовсе не единственный, возьмите сотни программ для компьютеров 30 летней давности, они по-прежнему хорошо на них работают.
Повеяло субъективными определениями… А что «черная работа» для неё?
На основании одной фразы тупо делать далеко идущие выводы. Тем более, что по сути фраза верная, лишь немного резкая по форме. А так в первую очередь для компании не выгодно, если сеньоры будут заниматься простыми задачами, т.к. в этом случае они по определению не смогут работать в состоянии потока, а значит не смогут работать эффективно. Если же это будет носить систематический характер, то специалист просто потеряет интерес к работе, которая ведёт его к профессиональной деградации, и уйдёт в другое место.
Мой комментарий (чуть выше) о том же самом как-то остался незамеченным… Действительно Ruby или Python дадут вычислить 1000!
Но делать это через рекурсию не стоит хотя бы потому, что глупо забивать стек при реализации задачи, вовсе не требующей рекурсии. Но Ruby и Python — скорее исключения (и то надо не recursion limit поднимать, а обычным циклом считать), т.к. для большинства языков программирования не хватит возможностей stdlib для написания за 5 минут метода, вычисляющего факториал (для теста хотя бы тот же 1000!). Просто тупо не будет целочисленного типа данных, в который влезет результат. Это можно обойти, но не за пару минут…
Cравнивать надо процент от зарплаты на руки, который ушёл на одинаковое кол-во товаров, как вы их назвали «расходы на жизнь». А то у вас получается идиотическая ситуация: живете в России, а думаете что можно купить на вашу зарплату в США. Определитесь уж с местом жительства, а то на доставке разоритесь быстрее, чем на колебаниях курса :-)
Вы какую-то хрень пишете, любая торгуемая на биржах валютная пара до поры до времени движется в коридоре. И пробой границы многолетнего коридора для любой валюты поистине эпохальное событие.
1) Свободная конвертируемость никак не коррелирует со стабильностью, хотя в данном случае правильно говорить не стабильность, а постоянное обесценивание за счёт доп.эммиссий. Доллар США — самая искусственно надутая валюта из всех маломальски известных. Держится исключительно на страхах и ни на чём больше.
2) А насчёт ресурсов, зачем велосипед изобретать… веками проверенный вариант — металлы (драгоценные и промышленные). Они не могут одномоментно подешеветь в 10 раз по отношению к рублю, а доллар — вполне может. С практической точки зрения сырьевые валюты (такие как рубль или австралийский доллар) гораздо более стабильны чем спекулятивные (такие как доллар США или евро), т.к. запасы сырья физически ограничены и негативно на сырьевые валюты может повлиять только серьёзная научно-техническая революция, при условии нахождения альтернативных видов сырья. А спекулятивные валюты могут рухнуть одномоментно из-за банкротства пары крупных банков, хотя их всячески будут поддерживать печатным станком резервные системы, пока это выгодно. Но надо понимать, что физически эти валюты обеспечены лишь страхами.
Автор просто неправильно описал назначение метода except!
По факту он удаляет все переданные ключи и возвращает хеш, а не удалённые значения. Так что ваши лучи ненависти к Rails не уместны, в stdlib этого нет. Хотя да, это всего лишь синтаксический сахар для
За 5 минут можно написать метод, вычисляющий факториал? Для некоторых языков можно, но в подавляющем большинстве случаев получится полная фигня, которая не посчитает даже факториал от 25, не говоря уж о трёхзначных аргументах.
> знает ли кандидат математику — некоторые не знают, что такое факториал ;)
это ж школьная программа
> легкость в применении алгоритмики и знания php — в частности применение рекурсии.
Применение рекурсии? Вы шутите? Вы возьмёте на работу человека, который считает факториал с помощью рекурсии? Не ну можно конечно, если рекурсия будет хвостовая и он пояснит, что компилятор развернёт её во время оптимизации. Но с другой стороны, в таком случае это будет просто выпендрёж. На практике же чем проще будут выдаваемые решения, тем лучше.
Сайты, которые не дают зарегистрировать аккаунт с помощью классической пары email+пароль, явно отдают несерьёзностью.
С другой стороны дополнить классический вариант авторизацией через соц.сети мало кому мешает.
Подойдут. Не знаю почему, видимо тут что-то на уровне психологии, но когда показываешь прототип с конечными шрифтами, то его начинают воспринимать как дизайн, что в корне не правильно и опускает уровень обсуждения до элементов оформления, что на стадии прототипа вообще ни малейшей роли не играет.
тоже хороший вариант :-)
Хотя по моему опыту ощущение «мультяшности» просто необходимо для прототипов, если вы собираетесь показывать их заказчику.
А вообще подобные шрифты обычно используют, чтобы было видно, что это набросок, а не дизайн.
А здания, которые стоят веками, составляют ничтожный процент от общего количества построенного за эти века. К тому же практически все они входят в 3 типа: совсем примитивные, совсем аварийные и памятники-архитектуры. Последние не используются по прямому назначению и для их поддержания в адекватном состоянии выделяются огромные бюджеты.
Однако ПО само по себе не изнашивается в отличии от зданий, т.е. срок жизни программного обеспечения ограничен только сроком жизни типа оборудования, на котором его можно запускать. Разумеется это как минимум десятки лет.
Другой вопрос в моральном устаревании, которое появляется из-за изменений требований к ПО, а отнюдь не из-за внутренних проблем в ПО. Так что пример с ПО для спутников вовсе не единственный, возьмите сотни программ для компьютеров 30 летней давности, они по-прежнему хорошо на них работают.
На основании одной фразы тупо делать далеко идущие выводы. Тем более, что по сути фраза верная, лишь немного резкая по форме. А так в первую очередь для компании не выгодно, если сеньоры будут заниматься простыми задачами, т.к. в этом случае они по определению не смогут работать в состоянии потока, а значит не смогут работать эффективно. Если же это будет носить систематический характер, то специалист просто потеряет интерес к работе, которая ведёт его к профессиональной деградации, и уйдёт в другое место.
Но делать это через рекурсию не стоит хотя бы потому, что глупо забивать стек при реализации задачи, вовсе не требующей рекурсии. Но Ruby и Python — скорее исключения (и то надо не recursion limit поднимать, а обычным циклом считать), т.к. для большинства языков программирования не хватит возможностей stdlib для написания за 5 минут метода, вычисляющего факториал (для теста хотя бы тот же 1000!). Просто тупо не будет целочисленного типа данных, в который влезет результат. Это можно обойти, но не за пару минут…
2) А насчёт ресурсов, зачем велосипед изобретать… веками проверенный вариант — металлы (драгоценные и промышленные). Они не могут одномоментно подешеветь в 10 раз по отношению к рублю, а доллар — вполне может. С практической точки зрения сырьевые валюты (такие как рубль или австралийский доллар) гораздо более стабильны чем спекулятивные (такие как доллар США или евро), т.к. запасы сырья физически ограничены и негативно на сырьевые валюты может повлиять только серьёзная научно-техническая революция, при условии нахождения альтернативных видов сырья. А спекулятивные валюты могут рухнуть одномоментно из-за банкротства пары крупных банков, хотя их всячески будут поддерживать печатным станком резервные системы, пока это выгодно. Но надо понимать, что физически эти валюты обеспечены лишь страхами.
Не думал, что он всё ещё на плаву… вот уж действительно плагин с большой историей.
но тогда ведь не получится блеснуть знанием ассемблера, что изначально предполагает эта задача :-)
По факту он удаляет все переданные ключи и возвращает хеш, а не удалённые значения. Так что ваши лучи ненависти к Rails не уместны, в stdlib этого нет. Хотя да, это всего лишь синтаксический сахар для
> знает ли кандидат математику — некоторые не знают, что такое факториал ;)
это ж школьная программа
> легкость в применении алгоритмики и знания php — в частности применение рекурсии.
Применение рекурсии? Вы шутите? Вы возьмёте на работу человека, который считает факториал с помощью рекурсии? Не ну можно конечно, если рекурсия будет хвостовая и он пояснит, что компилятор развернёт её во время оптимизации. Но с другой стороны, в таком случае это будет просто выпендрёж. На практике же чем проще будут выдаваемые решения, тем лучше.
Практическая ценность ведь не в LOC измеряется.