Совсем недавно в Сети появилась новость о том, что почти все препятствия на пути робомобилей исчезли, и осталось всего одна формальность — подписание соответствующего законопроекта губернатором штата Калифорния. Если кому интересно, то законопроект носит порядковый номер №SB1298. Теперь все формальности позади: губернатор подписал этот законопроект.

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

1. Управляемое бесконечное деление биологической клетки
2. Перенос сознания на другой более отказоустойчивый носитель.

Смысл статьи и последующей дискуссии — исследовать теорию именно по пункту 2, т.к. он подразумевает не копирование личности, когда ваш мозг скопирован в кого-то другого, но при этом вы остаётесь самим собой, а перенос именно вашего мозга на другой носитель, да так, чтобы вы не прекратили своего существования, мыслительного континуума, самоосознания.

152 455 деталек Лего.
307 килограмм.
2 метра.

Вот такие вот цифры. Это собранный из Лего движок Rolls-Royce Trent 1000, который поднимает в воздух Boeing 787 Dreamliner. И все 160 компонентов двигателя расположены в полном соответствии с оригиналом.

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

• Полнофункциональный механизм трансляции адресов (Full feature NAT) с поддержкой нескольких внешних IP-адресов; перенаправление портов с возможностью выбора порта назначения в локальной сети; переназначение ролей сетевых интерфейсов.
• Поддержка множественных PPP-туннелей для доступа в Интернет и подключения к виртуальным частным сетям (VPN).
• Возможность назначения нескольких дополнительных физических WAN-интерфейсов на порты встроенного коммутатора Ethernet.
• Резервирование подключения к интернету через USB-модемы 3G/4G и дополнительно назначаемые WAN-интерфейсы.
• Профессиональный интерфейс настройки через командную строку (Cisco like CLI). Все функции могут быть настроены с командной строки и сохранены в виде текстового файла.
• Пакетная сборка прошивки «по требованию». Функциональность устройства выбирается пользователем в веб-интерфейсе устройства и прошивается автоматически.

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


Официальный сайт проекта: Mozilla Seabird

Привет! Меня зовут Евгений Виноградов. Я работаю в Яндекс.Деньгах и участвую в работе группы W3C, посвященной стандартам интернет-платежей. Помимо нас и ещё нескольких платёжных сервисов, в неё вошли международные IT-компании, банки, регуляторы, организации, работающие с Bitcoin. На самом деле, группа существует уже больше трех лет. Всё это время она обсуждает содержание будущего стандарта для интернет-платежей, но только недавно — после очной встречи участников — дело заметно продвинулось вперед.



Мы в Яндекс.Деньгах не понаслышке знаем, с какими сложностями приходится сталкиваться разработчикам, например, интернет-магазинов. Сейчас для использования разных платёжных систем им приходится разбираться с документацией и особенностями каждой из них, а процесс подключения платёжных решений к мелкому магазину может растягиваться на месяцы. Если же подключение будет выполняться практически идентично, достаточно будет изучить процедуру один раз — и вы будете способны работать со всеми платежными системами.

Одним из наших предложений в рамках работы над стандартом стал способ инициализации платежа с условным названием «payto:» — по аналогии со всем известным сценарием отправки сообщений электронной почты через URI-схему «mailto:».

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

Некоторое время назад мы довольно подробно начали рассказывать об одной из базовых облачных технологий Яндекса — Elliptics. Сегодня настала очередь поговорить о другой — той самой, под которой работают «эльфы» и которая делает мечту о своем облаке чуть ближе к реальности. Речь пойдет о Cocaine.

Cocaine (Configurable Omnipotent Custom Applications Integrated Network Engine) — это PaaS-система (Platform-as-a-Service) с открытым исходным кодом, являющаяся по сути app engine и позволяющая создавать собственные облачные хостинги приложений — такие, как Google AppEngine, OpenShift, CloudFoundry или Heroku.



Всем известно, что облака могут решить все инфраструктурные проблемы, превратить издержки в прибыль и насытить вашу жизнь бесконечной радостью и счастьем на веки веков. Единственным препятствием на пути к этим целям являются, собственно, облака. IaaS, PaaS, SaaS? Whatever-as-a-Service? Какой именно загадочный набор букв нужно выбрать, чтобы всё наконец стало хорошо?

Мы потратили немало времени, изучая эти вопросы, отбирая лучшие, на наш взгляд, идеи и концепции, чтобы построить такую облачную платформу, которую хотелось бы немедленно установить, настроить и успешно использовать.

Каждый программист — проектировщик API. Хорошие программы состоят из модулей, а протокол взаимодействия модулей — это тоже API. Хорошие модули используются повторно.

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

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

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

NB: Это материал для тех, кто уже ознакомился с теоретической основой node.js и хочет, как говорится, с места в карьер — поскорей окунуться в разработку с применением этого инструмента. Никакой дедукции, only coding. Если заинтересовало, не стесняемся, проходим под кат.

В Яндексе работает больше 6000 человек, и, по некоторым оценкам, больше половины наших сотрудников имеют опыт в программировании. И конечно же, у каждого из этих людей есть своё самое правильное мнение о том, каким должен быть идеальный код.

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

Чтобы понять, какие свойства кода отстаивают разные стороны, я по горячим следам очередных бурных обсуждений решила спросить коллег, что такое красивый код и должен ли он вообще быть красивым? Достаточно того, чтобы он хорошо работал и был понятным? Или понятный код по умолчанию красивый?



В опросе участвуют bobuk, anatolix, anton, Андрей yafinder Плахов, Антон Самохвалов, Андрей Гулин, Владимир Иванов и другие. Суммарный опыт программирования всех участников этого микроинтервью на восьмерых составляет 198 лет.

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

На мой взгляд существует 3 популярных способа навесить событие на элемент в думе:

1. Через ID
2. Через то, что досталось от верстки
3. Через специальные классы

На повестке дня, уже не первый год, стоит вопрос о надёжности SSD накопителей. Кто-то отзывается негативно, мотивируя далеко не одним вышедшим из строя накопителем, а кто-то наоборот ратует за то, что накопители прекрасно чувствуют себя даже под нагрузкой и работают не один год. Я, пожалуй, отношусь ко второму лагерю и сейчас расскажу почему.

Каждый знает что такое тултип. Кто-то находит их крайне полезными, а кто-то обходит стороной. Судьба предрешила отнести меня к первой категории.

На разработку собственного варианта подсказок меня натолкнул Tipsy Tooltip используемый в Twitter Bootstrap. По началу я пользовался им, но все возможности плагина мне были не нужны и, будучи перфекционистом, лишний код смущал естество. Решил: напишу-ка я то, что нужно мне и ни строчкой больше. Написал и осмеливаюсь поделиться рецептом с сообществом. Авось кому-то приглянется…

Без качественного тестирования невозможно разрабатывать и поддерживать крупный веб-сервис. На ранних этапах его развития часто можно обходиться только ручным тестированием по заданному тест-плану, но с появлением новых фич и увеличением количества тест-кейсов довольствоваться только им становится все сложнее и сложнее. В этой статье мы расскажем о том, как автоматизируем функциональное тестирование веб-интерфейса Яндекс.Почты с помощью Selenium WebDriver и Node.js.

За свою долгую и плодотворную жизнь техногика я видел много пользовательских интефейсов. Очень-очень много, если без лишней скромности. Я общался с компьютерными системами при помощи перфокарт, перфоленты, магнитной ленты, переключателей адресов и данных на панели, печатной машинки, первых алфавитно-цифровых терминалов размером с хороший стол. Я был свидетелем рождения интерактивных компьютерных систем, графических и цветных мониторов, а прогресс, всего за считанные годы, от мотка перфоленты с машинкой «Консул» до Турбо-Си, не переставал меня поражать. В силу бэкграунда, склада ума и профессии, я в состоянии разобраться с любым устройством, понять его логику и возможности даже при отсутствии инструкций, минимуме элементов управления и сложности автомата состояний.

При мне менялись технологии и концепции. Тачскрины, голосовое управление, сенсоры движения, тачпэды, не говоря о всяких мышах — все это органично вписывалось в мой мир взаимодействия с приборами, и на этом пути не было ни особых потрясений, ни революций. Я спокойно и естественно считал себя типичным early adopter. Я был в сетях Fido и Compuserve, писал электронные письма до Эпохи интернета, общался в чатах и конференциях годы до появления ICQ, хранил файлы в «облаке» чуть ли не до рождения некоторых нынешних стартаперов в модной области Cloud. У меня даже несколько лет был собственный блог задолго до сегодняшнего блог-сумасшествия и десятков доступных платформ для блоггинга.

И так далее, и тому подобное.

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

Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

Что это такое?

LiveReload — это утилита, которая позволяет автоматически перезагружать страницу в браузере при изменение её кода и ресурсов(html, css, js, images, etc) на сервере. Кроме того LiveReload позволяет применять изменения в CSS и JavaScript без перезагрузки страницы.

На дворе 2013, прошло почти три года с момента, как мы заработали первую сумму денег и начали расти из компании из четырёх сотрудников. Недавно Джефф написал хороший пост об удалённой работе, в основном о нашем плане того, как заставить это работать. Сейчас, по прошествии нескольких лет, я бы хотел написать, что же на самом деле происходит.

Итак, что мы представляем из себя на данный момент? В Stack Exchange сейчас работают 75 человек, примерно половина занимается продажами (маркетинг и реклама), остальные же — созданием продуктов (разработка, дизайн, управление сообществами). БОльшая часть удалённо работающих сотрудников занимаются разработкой: 16 удалённых и 18 офисных разработчиков, сисадминов, дизайнеров. У нас команда-гибрид, которая, как мне кажется, лучшая в мире. Я руковожу отделом проектирования, так что буду говорить в основном о разработчиках, но это применимо ко всем должностям.

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

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

■ Что такое MVC или, лучше сказать, MV*?

Эти современные библиотеки дают разработчикам простой путь к организации кода, используя вариации паттерна проектирования, известного как MVC (Model-View-Controller). MVC разделяет задачи в приложении на 3 части:

(Окончание перевода статьи Эдди Османи о сравнении и выборе библиотеки для проекта со значительной ролью JS на клиенте.)
Содержание первой части:

■ Что такое MVC или, лучше сказать, MV*?
■ Когда нам нужен MV*-фреймворк JS?
■ Где же мы будем нуждаться в MV*, а где нет?
■ Проблема выбора: слишком много вариантов?
■ TodoMVC: общее приложение для обучения и сравнения
■ Предложенные нами критерии выбора фреймворка
■ Dojo и усложнение фреймворков на JavaScript
■ Коллекция TodoMVC (фреймворки, на которых сделаны реализации тестового приложения Todo)