Мне кажется, термин «окупаемость» в статье неудачно используется. Обычно под окупаемостью понимают период не компенсации расходов в результате возможной покупки компании, а компенсации расходов на создание бизнеса (стартовый капитал, аренда офисов, зарплата сотрудникам, реклама и тп).
Это вводит людей в заблуждение (особенно тех, кто не читает описание, а сразу смотрит на таблицу). Может быть, имеет смысл явно писать в таблице «окупаемость после покупки»?
Дико понравились фишки с методами и пропертями класса через лямбда выражения (через =>), и «интерполяция» строк типа '$salutation, $name'. Хотя количество языков от гугл настораживает (Go, Dart).
С другой стороны, ЭЦП--это устоявшийся термин, и в журнале он применяется совсем не в том значении. Что еще хуже, он применяется как раз в том же контексте (информационные технологии), где должно использоваться правильное значение.
Это как если бы не-экономисты акцией называли, например, ставку рефинансирования.
А журнал может кучу обывательских названий придумать. Отсканированная подпись, электронная подпись (без слова «цифровая») и тп.
По словам моего знакомого, который третий год учится в Китае, в частных поликлиниках у них такая система уже есть. Правда, электронные карточки действуют в рамках только данной сети больниц/поликлиник (если я не ошибаюсь).
В статье не упомянута еще одна важная проблема--изменение направления письма (справа налево, напр., в арабском языке). Это влечет за собой необходимость не только перевода, но и изменения интерфейса:
1. инвертирование по горизонтали положения многих элементов управления, например, кнопок OK и Cancel
2. перерисовку некоторых иконок (например, стрелка вправо в странах с письмом слева направо обычно обозначает «вперед», но в арабских странах она будет означать «назад»)
Да, я понимаю ваши аргументы (в основном вы говорите о рисках), но вот несколько моих:
1. Быстрота реализации. Из своего опыта (а также основываясь на стандартных повсеместных рекомендациях типа «не надо изобретать велосипеды»--то есть из опыта других инженеров) я думаю, что прикрутить nLog было бы быстрее, чем писать свой код. Может быть, скопировать ваш код будет теперь быстрее, чем прикрутить nLog с нуля. С другой стороны, если бы вы написали статью о том, как прикрутить nLog, это было бы так же быстро.
2. Риски. Конечно, есть риски в прикручивании nLog, но они малы, потому что это _очень_ популярная библиотека, и на любой подводный камень будет вопрос на stackoverflow. Плюс см. ниже.
3. «нет ничего более постоянного, чем временные решения». Вам приедется не раз сталкиваться с этой функциональностью, и, я думаю, чем раньше вы от нее избавитесь, тем будет лучше. И лучше всего--не писать ее сразу. То есть, на мой взгляд, длительное неудобство перевешивает риски начального этапа, о которых говорите вы.
4. Ваш код плохо решает проблему. Потому что очень много ошибок бывает при работе с базой. И вы о них никогда не узнаете.
Может быть, потратили бы чуть больше времени, зато оно с лихвой окупилось бы впоследствии (когда вам понадобилось бы писать еще и в текстовый файл; а в базу, например, писать только warnings and errors).
Я совершенно с вами согласен: технические термины переводить не стоит.
Но иногда полезно перевести для себя--чтобы лучше понять термин и удостовериться в собственном понимании. Я попробовал это проделать для REST--и у меня не получилось.
Более того, результаты опроса показывают, что как минимум две трети людей не понимают, _что_ на самом деле значит термин (потому что правильный ответ только один, хотя я и сам не уверен, какой из них).
Собственно, именно это я и хотел продемонстрировать, а заодно предложить подумать над значением термина, а заодно послушать мнения других.
При чем тут closure? Замыкание--это как бы автоматическая передача в анонимную функцию всех внешних переменных. А в статье имеется в виду поднятие к началу функции объявления переменных из этой же функции.
Согласно вашей же ссылке, w траснкрибируется (смотрим тест в скобках) «как 'в',… между двумя гласными не образующее дифтонга». В данном случае дифтонг не образуется, так что надо транскрибировать как «в».
По поводу этой фразы: «Имея СИФ, найти аттрактор просто.… Можно взять абсолютно любое начальное изображение и начать применять к нему СИФ.»
Мне кажется, в общем случае это не так. Из теории динамических систем известно, что может быть несколько аттракторов. И изображение будет приближаться к одному из них в зависимости от того, в бассейне какого аттрактора оно находилось.
да, это похожая схема, но не такая же. И, судя по этому описанию, с недостатками.
Если яндекс зайдет на mysexshop.com/?token=dsdskfljsdklfjlksdfjlksd&visit=/order/4222, то скрипт его не авторизует, и не редиректит на mysexshop.com/order/4222.
Но если яндекс зайдет на mysexshop.com/order/4222, то сможет ее проиндексировать.
То есть авторизация обязательно должна быть на финальной странице. А на промежуточной должно происходить нечто, что позволит отличить человека от поисковой машины (отработка js, например).
А почему вы куки какие-нибудь особые не можете класть клиенту, когда он оформляет заказ, а потом, когда приходит по get-запросу на сайт, проверять их? Конечно, он может зайти из другого браузера/компьютера, и вот тогда вы можете просить вбить пароль/фамилию/и тп. То есть в типичном случае пользователю не придется ничего вводить.
Еще идея: по ссылке отправлять пользователя на промежуточную страницу, с простеньким яваскриптом, который будет к исходному урлу дописывать какой-нибудь маркер (и оставлять хэш), а потом перенаправлять на страницу заказа. И уже на странице заказа вы будете проверять этот маркер. Тогда, когда бот будет индексировать исходный линк, яваскрипт не сработает, страница заказа маркер не прочитает и бота не пустит). Это решение вообще без ограничений, кажется.
На самом деле в F# условные конструкции реализуются через паттерн-матчинг (см Expert F#, стр 38). Кроме того, if/then/else в F#--это выражение, в отличие от императивных языков (http://msdn.microsoft.com/en-us/library/dd233231.aspx).
Вообще, мне кажется, что функциональные языки могут обходиться без условных конструкций. А поскольку императивные и функциональные языки эквивалентны (в том смысле, что любую императивную программу можно заменить функциональной, и наоборот), то сразу можно сказать, что любую программу можно переписать без условных конструкций. И без while/for. И без изменяемых переменных.
Это вводит людей в заблуждение (особенно тех, кто не читает описание, а сразу смотрит на таблицу). Может быть, имеет смысл явно писать в таблице «окупаемость после покупки»?
Но в остальном весьма интересно.
Это как если бы не-экономисты акцией называли, например, ставку рефинансирования.
А журнал может кучу обывательских названий придумать. Отсканированная подпись, электронная подпись (без слова «цифровая») и тп.
1. инвертирование по горизонтали положения многих элементов управления, например, кнопок OK и Cancel
2. перерисовку некоторых иконок (например, стрелка вправо в странах с письмом слева направо обычно обозначает «вперед», но в арабских странах она будет означать «назад»)
и тп
1. Быстрота реализации. Из своего опыта (а также основываясь на стандартных повсеместных рекомендациях типа «не надо изобретать велосипеды»--то есть из опыта других инженеров) я думаю, что прикрутить nLog было бы быстрее, чем писать свой код. Может быть, скопировать ваш код будет теперь быстрее, чем прикрутить nLog с нуля. С другой стороны, если бы вы написали статью о том, как прикрутить nLog, это было бы так же быстро.
2. Риски. Конечно, есть риски в прикручивании nLog, но они малы, потому что это _очень_ популярная библиотека, и на любой подводный камень будет вопрос на stackoverflow. Плюс см. ниже.
3. «нет ничего более постоянного, чем временные решения». Вам приедется не раз сталкиваться с этой функциональностью, и, я думаю, чем раньше вы от нее избавитесь, тем будет лучше. И лучше всего--не писать ее сразу. То есть, на мой взгляд, длительное неудобство перевешивает риски начального этапа, о которых говорите вы.
4. Ваш код плохо решает проблему. Потому что очень много ошибок бывает при работе с базой. И вы о них никогда не узнаете.
5. Все аргументы из коммента ниже :-)
Тем не менее, спасибо за статью!
Может быть, потратили бы чуть больше времени, зато оно с лихвой окупилось бы впоследствии (когда вам понадобилось бы писать еще и в текстовый файл; а в базу, например, писать только warnings and errors).
Но иногда полезно перевести для себя--чтобы лучше понять термин и удостовериться в собственном понимании. Я попробовал это проделать для REST--и у меня не получилось.
Более того, результаты опроса показывают, что как минимум две трети людей не понимают, _что_ на самом деле значит термин (потому что правильный ответ только один, хотя я и сам не уверен, какой из них).
Собственно, именно это я и хотел продемонстрировать, а заодно предложить подумать над значением термина, а заодно послушать мнения других.
Мне кажется, в общем случае это не так. Из теории динамических систем известно, что может быть несколько аттракторов. И изображение будет приближаться к одному из них в зависимости от того, в бассейне какого аттрактора оно находилось.
Если яндекс зайдет на mysexshop.com/?token=dsdskfljsdklfjlksdfjlksd&visit=/order/4222, то скрипт его не авторизует, и не редиректит на mysexshop.com/order/4222.
Но если яндекс зайдет на mysexshop.com/order/4222, то сможет ее проиндексировать.
То есть авторизация обязательно должна быть на финальной странице. А на промежуточной должно происходить нечто, что позволит отличить человека от поисковой машины (отработка js, например).
Еще идея: по ссылке отправлять пользователя на промежуточную страницу, с простеньким яваскриптом, который будет к исходному урлу дописывать какой-нибудь маркер (и оставлять хэш), а потом перенаправлять на страницу заказа. И уже на странице заказа вы будете проверять этот маркер. Тогда, когда бот будет индексировать исходный линк, яваскрипт не сработает, страница заказа маркер не прочитает и бота не пустит). Это решение вообще без ограничений, кажется.