Дональд Кнут рассказывает про маму и папу, вспоминает о том, как он учился читать, как шкодил в школе. Откровенничает о первом писательском опыте и намекает на «пасхалки» со звездой эротики в своих книгах.

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

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

Если вы еще не слышали про meteor, значит вы вообще не следите за миром JavaScript, не интересуетесь вебом и непонятно каким образом сюда попали.
Пусть так.

James Kyle как-то раз взял и написал пост про структуры данных, добавив их реализацию на JavaScript. А я взял и перевёл.

Дисклеймер: в посте много ascii-графики. Не стоит его читать с мобильного устройства — вас разочарует форматирование текста.

Я не самый талантливый кодер в мире. Правда. Так что я стараюсь писать как можно меньше кода. Чем меньше кода я пишу, тем меньше кода может ломаться, поддерживаться и требовать пояснений.

А еще я ленивый — мед, да еще и ложкой (я решил использовать в статье аналогии с едой).

Но, оказывается, что единственный гарантированный способ повысить производительность в вебе — это писать меньше кода. Минифицировать? Окей. Сжимать? Ну, да. Кэшировать? Звучит неплохо. Вообще отказываться кодить или использовать чужой код изначально? А вот теперь — в яблочко! Что есть на входе — должно выйти на выходе в той или иной форме, независимо от того, смог ли ваш сборщик растворить и переварить это своими желудочными соками (я, пожалуй, откажусь от пищевых аналогий).

И это не все. Кроме видимых улучшений производительности, где вам требуется то же количество кода, но его сначала нужно разжевать (не смог удержаться), вы также можете сэкономить. Моему провайдеру без разницы, посылаю ли я кучу маленьких писем или одно большое: все складывается.

В стремлении к уменьшению мне больше всего нравится вот что: в конце остается только то, что реально нужно, только то, что по-настоящему требуется пользователю. Огромная фотка какого-то чувака, пьющего латте? Выкинуть. Кнопки социальных сетей, которые подсасывают кучу левого кода и ломают дизайн страницы? Пинок под зад им. Эта хреновина на JavaScript, которая перехватывает правый клик и показывает кастомное модальное окно? Выставить на мороз!

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

В нашем предыдущем посте мы рассказали историю Acronis: как все начиналось больше 10 лет назад. Кому-то, вполне возможно, она показалась впечатляющей, кому-то — просто интересной, а в действительности — это история компании, которая когда-то поднималась из простых серых зданий, переживала вместе со страной кризис за кризисом и осваивала новые рынки. В целом, мы давно заметили, что компании с особым духом, с неповторимым драйвом притягивают таких же людей, которые приходят, говорят «Это моё!» и остаются на долгие годы. Таким и есть Станислав Протасов, сооснователь и глава разработки Acronis. Кстати, 27 апреля (уже сегодня) Станислав выступит с открытой лекцией в своей альма-матер, в МФТИ. Но об этом чуть позже.

Лампочка на пожарной станции в Ливерморе (Калифорния) производства Shelby Electric светит практически непрерывно с 1901 года, уже более 1 миллиона часов. В 2015 года она внесена в Книгу рекордов Гиннесса как лампочка с наиболее длительным сроком службы. Фото: Dick Jones / EPA

23 декабря 1924 года представители крупнейших компаний по производству осветительных приборов встретились в Женеве (Швейцария) и договорились о создании Phoebus — вероятно, первого в истории промышленного картеля мирового масштаба. Компании обсудили проблему качества продукции. Проблема была в том, что качество ламп накаливания слишком сильно увеличилась, а продолжительность их службы угрожала бизнесу. Другими словами, лампы служили настолько долго, что начал снижаться объём продаж.

В этом выпуске «Без слайдов» гостем выступил Вадим Макеев aka pepelsbey, евангелист компании Opera Software, один из самых известных фронтенд-людей в стране, организатор многих мероприятий в индустрии.

Мы успели обсудить:

• эволюцию WebKit;
• путь Microsoft и новую модель браузера;
• архитектуру современных браузеров;
• как Opera выбирала между WebKit и Blink;
• стандартизацию в вебе;
• насколько трудна работа веб-разработчика;
• JavaScript и его «продолжения»;
• jQuery, и почему он все еще нужен;
• HTTP/2;
• ритм жизни евангелиста;
• мобильный веб и Opera Mini;

Интервью взято в феврале, но руки дошли до публикации только сейчас.

Видео-версия нашей беседы вот тут:


А для тех, кто предпочитает читать, — под катом расшифровка нашей беседы.

Идея для написания этой статьи возникла прошлым летом, когда я слушал доклад на конференции BigData по нейронным сетям. Лектор «посыпал» слушателей непривычными словечками «нейрон», «обучающая выборка», «тренировать модель»… «Ничего не понял — пора в менеджеры», — подумал я. Но недавно тема нейронных сетей все же коснулась моей работы и я решил на простом примере показать, как использовать этот инструмент на языке JavaScript.

Мы создадим нейронную сеть, с помощью которой будем распознавать ручное написание цифры от 0 до 9. Рабочий пример займет несколько строк. Код будет понятен даже тем программистам, которые не имели дело с нейронными сетями ранее. Как это все работает, можно будет посмотреть прямо в браузере.

Сегодня вышел текст о том, как человек перешёл с Sublime на VIM. В комментариях, как обычно это бывает, появились сообщения в духе "Зачем мне тратить время на Vim, если есть IDE, где всё работает?" (люди даже статьи на эти темы пишут). Хотел внести свои пять копеек, но объём написанного плавно перевёл текст из разряда "комментарий" в разряд небольшой статьи.

В целом, всё, что ниже — это вкусовщина, конечно. Нравится вам ваша IDE (или ваш текущий инструмент), да и пожалуйста. Используйте для текущих задач то, чем вы владеете лучше всего, это аксиома эффективной работы. Но если у вас вдруг появилось немного времени на повышение вашей эффективности в целом, то попробую вас заинтересовать именно Vim'ом, сравнивая его с некой обобщенной IDE.

Многим известно, что в мобильной версии Safari можно отсканировать свою банковскую карту. Но многие ли разработчики умеют создавать формы, поддерживающие эту возможность?

Готов поспорить, что немногие.

Дело осложняет полное отсутствие документации от Apple по работе этой функции. Но тут есть один момент. Функция сканирования банковских карт является подмножеством автозаполнения — браузерного функционала, давно игнорируемого веб-разработчиками. Понятно, почему они не уделяли ему должного внимания: когда регулярно заполняешь форму тестовыми данными, автозаполнение обычно мешает. Но для наших пользователей это важная функция. В Google выяснили, что при использовании автозаполнения пользователи на 30% быстрее заполняют формы. Так что давайте изучим работу автозаполнения, разберёмся, как создавать формы, поддерживающие кросс-браузерное автозаполнение, и воспользуемся преимуществами новых возможностей наподобие сканирования банковских карт.

Я эксперт в области того, как в технологиях используются слабые места нашей психики. Вот почему я проработал последние три года как специалист Google по этике в дизайне. Моя работа состояла в проектировании ПО таким образом, чтобы защитить умы миллиарда людей от «уловок».

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

Как технология эксплуатирует слабые места нашего разума?

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


Это я, творящий «волшебство» при помощи ловкости рук, на дне рождения моей матери

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

И я хочу показать вам, как они это делают.

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



Разовьём этот тезис подробнее.

Когда я думаю о программисте как о хозяине, я имею в виду, что он программирует для себя. Имея все ресурсы, все средства (виртуально или физически — неважно!) в своём распоряжении, он является единственным и окончательным судьёй своим действиям и их результату.

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

Естественно, что это различие замечалось многими. Ф.Л.Бауэр [1] называет работу программиста-слуги программированием по контракту. Соответственно можно назвать работу программиста-хозяина программирование для себя. Э.Сандевал [2] развивает близкий подход, выделяя группу «оконечных» программистов. Иногда это различие проводят, употребляя для слуги и хозяина термины профессионального и непрофессионального программирования соответственно. Такая трактовка допустима, если мы будем исследовать социальную сторону программирования как деятельности, например, его профессиональную этику. Если же говорить о программировании, имея в виду его внутреннее содержание, то в этом случае взгляд на программиста-хозяина как на непрофессионала может привести к недоразумениям.

Часть 2
Часть 3

Введение (Языковая природа абстрактных понятий)

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

Вступление

Большинство веб-разработчиков сталкивалось с задачей перевода веб-сайта на несколько языков. Миссия это достаточно простая, и решение, как правило, относится к рутине. Уверен, что многие согласятся с утверждением, что локализация – это скучная, некреативная часть проекта.

В этой статье я хотел бы вынести на обсуждение альтернативную модель перевода веб-сайтов. Если попытаться описать принцип в одном предложении, то это: CDN, который переводит контент между пользователем и оригинальным источником.

Привет, Хабр!

Я постараюсь докопаться до первоисточников IT-технологий, разобраться, как мыслили и какие концепции были в головах у первопроходцев, о чем они мечтали, каким видели мир будущего. Для чего задумывались «компьютер», «сеть», «гипертекст», «усилители интеллекта», «система коллективного решения задач», какой смысл они вкладывали в эти понятия, какими инструментами хотели добиться результата.

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

Уважаемые хабравчане.

Поскольку дискуссия вокруг статьи идет весьма активно, Жан-Жак Дюбре (он читает комментарии) решил организовать чаты в gitter.

Вы можете пообщаться с ним лично в следующих чатах:
https://gitter.im/jdubray/sam
https://gitter.im/jdubray/sam-examples
https://gitter.im/jdubray/sam-architecture

Также автор статьи разместил примеры кода здесь: https://bitbucket.org/snippets/jdubray/

По поводу кода он оставил следующий комментарий:

I don't code for a living, so I am not the best developer, but people can get a sense of how the pattern works and that you can do the exact same thing as React + Redux + Relay with plain JavaScript functions, no need for all these bloated library (and of course you don't need GraphQL).

Привет, Хабр! Меня зовут Владимир, мне 28 лет и я наркоман наркоман. Мой наркотик – простота. На простоту я подсел из-за своего перфекционизма, которым меня наградили при рождении.

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

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

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

Привет, Хабр!

Одна из сложных задач современной разработки — это программирование пользовательского интерфейса. С увеличением количества элементов сложность увеличивается нелинейно и совладать с огромным количеством вариантов, состояний и переходов становится практически невозможно. Фреймворки вроде Angular со своим двусторонним связыванием пытается решить эту проблему, но на фундаментальном уровне ничего не меняется.

Со-основатель, технический директор и главный учитель нашего образовательного проекта Хекслет Кирилл Мокевнин рассказывает про сложность программирования интерфейсов и каким образом можно совладать со сложностью если вы знакомы с одной базовой концепцией информатики. Заодно расскажет и покажет идеальный JS-фреймворк для программирования UI.