Чтение в оригинале для многих является проблемой. Обилие незнакомых слов усложняет восприятие текста и приводит к потере энтузиазма. Такое происходит, когда сложность текста превосходит ваш текущий уровень, или когда вы читаете текст не по вашей тематике. Технари могут без проблем общаться на рабочие темы, но пасуют перед статьями о политике, музыке и серьёзной художественной литературой.

Цель нашего сервиса — решить эту проблему.

Несколько лет назад мы писали на Хабре об этом сервисе. Идея нашла отклик, сайт приобрел постоянных пользователей, хотя в то время сервис мог только показывать статистику слов из текста. За последние месяцы сервис стал умнее.



Ключевая цель сервиса — дать людям возможность читать и смотреть в оригинале то, что им интересно. И при этом максимально упростить работу с незнакомыми словами.

Добрый день!

Я хочу представить небольшой сервис, который создан, чтобы помочь в эффективном пополнении словарного запаса для английского языка:



Если коротко, работает он следующим образом.

1. Вы загружаете текст, который хотите прочитать. Это может быть URL статьи из интернета, книга или статья в pdf, doc, txt, ps или субтитры.

2. Система строит статистику слов и отображает слова, отсортированные по частоте употребляемости в тексте. Предварительно к словам применяется лемматизация (т. е. слова make и made будут считаться идентичными).

3. Вы отмечаете знакомые слова, а также слова, которые надо изучить.

4. Вы печатете слова, которые необходимо изучить, в удобном для вас формате (в том числе, с коротким англо-русским переводом, т. е. не полную словарную статью).

Каждый из нас хочет быть творцом. Каждый хочет создавать шедевры. Но не каждый может оторваться от рутины, своих типовых задач и начать творить. Возможно, чтобы как-то это оправдать, люди начали придавать обычной, в смысле, ремесленной деятельности возвышенный смысл. Из-за этого сегодня часто мы слышим об «искусстве программирования», «искусстве управления проектами», а также о других «искусствах». Если прямо спросить авторов подобных учений и пособий, навряд ли они смогут ответить на вопрос, что же есть это самое «искусство», и почему оно не «наука» или вообще не какое-нибудь «дао» (которое тоже частенько встречается в названиях книг).

Лев Николаевич Толстой, будучи, в первую очередь писателем, интересовался и другими видами того, что принято сегодня называть «искусством» в широком смысле слова. В результате у него появилась маленькая заметка «Об искусстве» и большая монография «Что такое искусство?»

Я постараюсь изложить, что же такое искусство по мнению Льва Николаевича, что необходимо для того, чтобы искусство таковым являлось, а также каковы признаки поддельного искусства (последнее перенесено в отдельную заметку). Всё это, насколько возможно, изложено применительно к IT и проиллюстрировано примерами.

Как-то в тренировочном зале для скалолазов я наблюдал за мастером спорта, который лез только что накрученную им трассу. Это была трасса категории 5а.

Что такое «5а»? Это стенка для новичков. Если вы первый раз на скалодроме, категория 5а для вас. Вы её пролезете.

Но как он лез эту трассу! Плавность движений поражала. Любой может пролезть эту трассу — но я первый раз видел, чтобы человек делал такие переходы с ноги на ногу, так изящно придерживался за зацепки. Казалось, что он не лезет трассу — он её, если хотите, гладил, разговаривал с ней своими движениями. Каждое движение было настолько экономичным, что простая ходьба, казалось, отнимает больше сил.

Я потом тоже попробовал эту трассу. Но движения тела казались угловатыми, я постоянно цеплял ногой стенку, мне приходилось подтягиваться на руке, чтобы завершить движение. Потому что я не мастер спорта. После этого я начал лазить простые трассы наряду с теми, которые находятся на грани моих возможностей.

Похожая вещь происходит у хороших разработчиков и в веб-проектах. Освоили скриптовый язык — давайте делать сайт. Три — пять сайтов, и уже бежим в сторону сервисов. Парочка сервисов — и подавай нагрузочное программирование, управление проектами, управление контентом, новые концепции и ультрасовременные идеи. И так далее. Интересно, что такие люди (несомненно, очень способные!) постоянно находятся в «новичковой» зоне. Они работают в той сфере, где они пока не специалисты. А став специалистами, переходят в другую область.

Забывая, что мастерство постигается не только категорией сложности «red point»*, но также и красотой исполнения простых вещей.

*Red point — скалолазный сленг, означает маршрут с максимальной категорией сложности, на которую способен тренирующийся.

P. S. Думаю, вы поняли: это не призыв не развиваться.

Введение

Сегодня множество интернет-сервисов взаимодействуют друг с другом через интернет. Особый класс взаимодействий — те, в которых осуществляется передача конфиденциальной информации (личные данные, секретные сообщения) или команд, выполнение которых должно быть кем-то однозначно подтверждено (например, перевод денег или публикация сообщения от чьего-то имени). Очевидно, что подобные сервисы должны быть надёжно защищены от злоумышленников.

К сожалению, не все разработчики задумываются о степени защищённости своих приложений. Проблема несколько усугубляется тем, что многие представители электронного бизнеса разрабатывают протоколы, которые, будучи реализованными в конечных сервисах, могут создать серьёзные уязвимости, если использовать их без должного понимания.

Задача данной статьи — кратко описать возможные типы атак при межпроектном (т. е. сервер-сервер) взаимодействии и средства защиты от них — с тем, чтобы более вдумчиво использовать готовые протоколы и разрабатывать свои. Предварительно будут рассмотрены основы информационной безопасности, так как зачастую знания конечных разработчиков в этой области бывают несколько отрывочными.

Защита (или отсутствие защиты) от различных типов атак демонстрируется на примере протоколов популярных сегодня систем: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa и PayPal (платёжные системы), а также OpenID, OpenAuth, OAuth (децентрализованная аутентификация).

Наверное, каждый разработчик встречался с задачей запуска одного проекта на разных компьютерах. В простом случае это машина разработчика и «боевой» сервер. Ещё сложнее ситуация, если в разработке участвуют несколько человек, и у каждого свои настройки.

Сложность здесь в том, что разное окружение (доступ к БД, расположение файлов и проч.), будучи «жестко» прописанным в файле конфигурации, заставляет нас постоянно этот файл править. Кроме того, файлы настроек часто заливаются в репозиторий, и после очередного обновления кода у вас всё перестаёт работать.

Для решения проблемы я использовал два метода.

Добрый день. В этой заметке я хотел бы поговорить об ограничениях, которые выставляются в сервисах на логины.

Создавая очередной сервис, я исхожу из следующих соображений:
1. Логин не должен быть слишком короткий (у меня сейчас от 3 символов включительно, для более крупных систем, типа GMail, используется от 6).
2. Логин не должен быть слишком длинный, иначе в каком-нибудь интерфейсе он начнёт что-нибудь неправильно распирать. Я использую логины до 20 символов, но интересно выслушать ваши мнения по этому поводу.
3. Логин может использоваться в адресной строке, при интеграции с SMS и проч. Поэтому оставляем только латинские символы, цифры, подчёркивание, дефис и точку.
3а. Если логин может быть использован как имя поддомена, то эти условия сокращаются до символов латинского алфавита, цифр и дефиса (дефис не может быть первым и последним, он не может повторяться).
4. Иногда очень удобно использовать двойную навигацию: по логину и ID. Например, у нас на одном сервисе используется адрес domain.com/users/<login> для пользователей с логином и domain.com/users/<id> для тех, у кого нет логина (т. н. виртуальные профили, которые зарегистрированы администрацией или другими пользователями). Это приводит к тому, что логин не может состоять только из цифр, чтобы не путать его с идентификатором.
5. Слова-исключения: www, mail, ns1, ns2, ns3, ns4, admin, god, moderator, editor. Первые 6 являются исключениями для совместимости с поддоменами. А какие слова-исключения используете вы?

И основной вопрос к читателям: какие ограничения стоят у вас, и что я забыл?

Все гики с дизайнерами наперебой кричат, что нужно выводить даты и числа в человекопонятном и человекочитаемом формате.

25 ноября 2005
Найдено 11 статей
2 результата поиска

Не дай Бог написать «Результатов поиска: 2» — засмеют и оплюют!

Но особенно можно гордиться, если вы заменили числительное словом.

One search result
Two articles were found

Проблема в том, что глаз к такому не привык. Сегодня, настраивая аккаунты в GMail, я долго не мог понять, почему мне не пришло тестовое письмо.

Занимаясь разработкой ПО уже несколько лет, я последнее время стал часто задумываться о том, что влияет на качество разрабатываемого продукта. Внедрение новых практик (тех же составляющих XP/Agile/Scrum) очень быстро показало, что дело совсем не только в организации разработки — ведущими всегда оказываются личные качества разработчиков. Мы не будем сейчас погружаться с головой во все аспекты качества ПО, но рассмотрим только один из них: качество кода.

Типичной практикой является оценка продукта по его внешней составляющей, однако при создании Open Source решений, а также, банально, при модификации существующей бизнес-логики, для программиста именно исходный код является конечным продуктом, с которым ему приходится работать.

Задача этой статьи — не просто перечислить качества хорошего кода, этим занимаются слишком часто, и это было бы не столь интересно. Здесь я просто кратко перечислю найденное. Затем мы посмотрим на некоторые аналогии.