О чем это

Я долгое время был адептом идей о равенстве, свободе и братстве том, что существует красная таблетка.

— Что можно с помощью ООП решить все проблемы масштабирования программ;
— Что с помощью одной методологии можно выстроить разработку проектов;
— Что с помощью нескольких гениальных книг можно научиться проектировать интерфейсы.

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

Я не сделаю, возможно, в этом посте никаких открытий. Но сэкономлю вам пару лет, если вы решитесь поверить моему опыту.

Я программирую уже более 30 лет. И мой путь в программировании тянется от микропроцессоров Z80 и 6502 до современных машин, от таких языков программирования как BASIC, assembly, C, C++ до Tcl, Perl, Lisp, ML, occam или arc, Ruby, Go и проч.

Вот список того, что я постиг в программировании:

0. Программирование удел ремесленника, а не ученого или инженера

Программирование больше походит на ремесло нежели на науку или инженерную дисциплину. Это комбинация навыков и опыта выраженная в умении применять инструменты. Ремесленник выбирает необходимые инструменты(а если требуется, то создает свои) и учится применять их.

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

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

Это шаблон описания сути вашей компании или проекта в одном предложении. Я открыл его для себя во время стажировки в США. Составив его, мы реально становимся сильнее. В последствии мне это помогло выбрать правильный курс, сфокусироваться и расставить приоритеты.

От переводчика

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

Также прошу прощения за отсутствие перевода словосочетания “computer science”. В русском языке нет адекватного ему словосочетания. Всякие «информатики» и «компьютерные науки» — это либо дискредитировавшие себя понятия, либо бессмысленные переводческие суррогаты. Английское понятие “computer science” содержит историческую игру слов, которая в переводе на русский язык должна выглядеть как-то так: «науки о вычислениях, обработке информации и вычислительных устройствах». Думаю, лучше оставить оригинальное “computer science”. Во всяком случае, в таком виде это словосочетание позволит вам самим подобрать нужный контекст из всего многообразия, представляемого им в оригинале.

Почему я решил перевести этот текст (ведь он короткий и не особо насыщенный откровениями)? Потому, что это выступление Кармака. А он, как-никак, знаковая фигура в отрасли разработки ПО. То, что написано ниже, показывает отрыв теории разработки ПО от практики. Ведь, если эти мысли посещают такого разработчика и выносятся на QuakeCon, — то что тогда творится в головах рядовых прикладных программистов?

Я хотел бы начать с истории:

Учитель керамического дела объявил в день открытия, что разобьет класс на две группы. «Те, кто сидят слева» — сказал он: «будут оцениваться только по количеству проделанной работы, те, кто справа — только по её качеству». Его методика была проста, в последний день он принесет весы и взвесит работу группы «количество»: 50 фунтов горшков это «5», сорок фунтов горшков это «4» и так далее. Те, кто оцениваются по «качеству», однако, должны сделать один, пусть и совершенный, горшок, чтобы получить «5». Время сдачи пришло, и обнаружился любопытный факт: работы лучшего качества были сделаны в группе, оцениваемой по количеству. Похоже, в то время, как группа «количество» упорно штамповала свои работы и училась на своих ошибках, группа «качество» теоретизировали об идеале и, в конце концов, только и могла показать свои старания и грандиозные теории об идеале, а также кучу бесполезной глины.

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

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

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

Это перевод и форма повествования от первого лица сохранена. Автор — Бен Бойтер, бакалавр информационных технологий в Университете Чарльза Стерта (CSU).


Большинство людей не в курсе, но моей диссертацией была программа для чтения текста с изображения. Я думал, что, если смогу получить высокий уровень распознавания, то это можно будет использовать для улучшения результатов поиска. Мой отличный советник доктор Гао Джунбин предложил мне написать диссертацию на эту тему. Наконец-то я нашел время написать эту статью и здесь я постараюсь рассказать о всем том, что узнал. Если бы только было что-то подобное, когда я только начинал…

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

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

У меня неплохо получалось — более 60% изображений было успешно разгадано из моей небольшой коллекции. Довольно неплохо, учитывая количество разнообразных изображений в интернете.

Когда я вижу друзей, которые вкалывают в два раза больше, а зарабатывают в четыре раза меньше, каждый раз начинается разговор:
— А ты бы не хотел поработать программистом? Ты же реально умный. Может ты просто не на своем месте?

В результате я переучиваю своих друзей и знакомых на программистов. Весь процесс занимает от двух до трех месяцев. 25 уроков по 4 часа. Потом все смогли устроиться программистами.
Эта статья не о том, как надо учить, скорее просто описание процесса, который работает.

Автор оригинальной статьи — Майкл Эбраш, человек и пароход. Для тех, кому лень изучать википедию, отмечу, что это программист с более чем 30-летним стажем работы, который в свое время помог Кармаку сделать Quake, разработал GDI для Windows NT, приложил руку к созданию первых двух версий Xbox, а сейчас работает в R&D-отделе компании Valve.
В своей заметке он вспоминает, как зарождалась индустрия 3D-игр вообще и Valve в частности, рассказывает про свой опыт работы в различных корпорациях, приоткрывает завесу внутренней кухни Valve и ищет новых сотрудников. Статья большая, и я посчитал ее достаточно интересной для того, чтобы перевести на хабр.

---

Всё началось с Лавины*.

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

В 1994 году я уже несколько лет как работал на Microsoft. Однажды вечером, когда моя дочка рассматривала книги в магазине Little Professor в Sammamish Plateau, мне посчастливилось заметить Лавину на полке. Я взял книжку, прочитал первые страницы, решил купить и в итоге проглотил её за день. Параллельно я начал задумываться о том, что 80 процентов описанного в ней осуществимо прямо сейчас, и мне захотелось реализовать это сильнее, чем когда-либо вообще хотелось сделать что-то с компьютером — я всю жизнь читал научную фантастику, и вдруг мне выпал шанс превратить её в реальность. Так я попытался начать в Microsoft проект по созданию технологии сетевого 3D.

Фундаментальный поворот к параллелизму в программировании

Автор: Герб Саттер
Перевод: Александр Качанов

The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
(By Herb Sutter)

Ссылка на оригинал статьи: www.gotw.ca/publications/concurrency-ddj.htm

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

Данная статья достаточно старая. Ей уже 7 лет, если считать с момента ее первой публикации в начале 2005 года. Помните об этом, когда будете читать перевод, так как многие вещи, которые для вас уже стали привычными, для автора статьи в 2005 году были в новинку и только-только появлялись.

Ральф вошел в помещение ангара №1 в 8:30 утра, как делал это ежедневно уже несколько лет. Его взгляд сразу же устремился к центру зала, где на постаменте, окруженный множеством приборов и паутиной кабелей, находился смысл его работы. Собственно говоря, не только его — миллионов людей по всему миру. Первый инопланетный корабль. Полтора десятилетия назад он совершил аварийную посадку и был частично поврежден, оставив, однако, весьма много материала для изучения. Настоящим чудом стало то, что политики и учёные после этого события не переругались, а смогли организовать эффективное изучение свалившегося с небес подарка. На реверс-инжиниринг корабля были брошены лучшие умы планеты. Ральф, возглавляющий группу изучения приборов связи, стоял в ангаре и в который раз любовался стремительной, похожей на стрелу в полёте, формой корабля. Он вспоминал всё, что случилось за последние годы.

Уважаемые читатели и писатели Хабра!

Хочу сказать спасибо всем участникам этого обсуждения за их искреннее желание сделать нашу страну лучше. Это видно во всех вопросах, заданных здесь, даже если они порой звучат жёстко и предубеждённо. Я посчитал важным ответить на вопросы, потому что ABBYY слишком давно не рассказывала о том, чем мы занимаемся, и как мы это делаем. А отсутствие информации порождает много нелепых догадок. Итак, время отвечать на вопросы.

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

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

В минувшую субботу в Мурманском политехническом лицее прошло занятное мероприятие — настоящая «Битва роботов». Про похожее мероприятие в Питере писали на Хабре, но трансляция закончилась, потому я решил опубликовать фотоотчет с аналогичного мероприятия.

Перевод статьи из блога Джефа Этвуда, одного из основателей Stack Exchange Network, сети вебсайтов, посвященных работе с вопросами и ответами в различных областях. Среди прочих вебсайтов этой сети стоит выделить Stack Overflow — самый первый вебсайт, созданный в рамках Stack Exchange Network и посвященный вопросам и ответам в области программирования. Отдельная благодарность karaboz за помощь и вдохновение.

---

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

Когда люди спрашивают меня о самой большой ошибке, которую я совершил в процессе создания Stack Overflow (Прим. переводчика — далее SO) я рад, что не надо выдумывать и говорить банальности. Я могу честно и открыто рассказать об огромной, нелепой и, до смешного, дурацкой ошибке, которую совершил в самом начале разработки SO. Что ещё хуже, я могу рассказать о такой ошибке, которую продолжал совершать потом ещё и на протяжении девяти месяцев на фоне продолжающихся протестов сообщества.

Я нашел еще один (очень простой) график, отражающий рейтинг языков программирования. Всё элементарно: по горизонтали — количество проектов на Github, по вертикали — количество вопросов на Stackoverflow.



Я позволил себе провести на этом графике две красные диагональные линии, чтобы показать как наглядно отделены друг от друга мейнстрим (C++, C#, Java, PHP, Javascript и т.д.), группа «альтернативного мировозрения» (Scala, Haskell, Erlang, Prolog, Lisp) и откровенный трэш (всё, что ниже). По-моему, проще некуда. Никаких там годовых колебаний в полтора процента, высчитанных по непонятным формулам.
Взято тут.

UPD: сорри за мини-троллинг со словом «трэш» — зато он породил весьма интересную дискуссию в комментариях. Всем высказавшимся — спасибо.

Спасибо небу за то, что в субботу шел дождь, и я это прочитал (а вы скажите спасибо за то, что перевел). В воскресенье, однако, светило солнце и форматирование текста было отложено.

Отдельное спасибо автору, за разрешение отдельной публикации.

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

Около полугода назад я написал простой джейкверный плагин для галерей на сайтах. Назвал его Фоторамой и выложил в интернет. По клику кроссфейдом показывалась следующая фотография, клик с шифтом мотал назад — вот и всё.

За эти месяцы Фоторама повзрослела, обзавелась сайтом с логотипом и, думаю, теперь можно написать о ней на Хабре.

Введение

В этой статье я хочу рассказать об использовании некоторых конструкций, применяющихся для осуществления неблокирующей синхронизации. Речь пойдёт о ключевом слове volatile, функциях VolatileRead, VolatileWrite и MemoryBarrier. Мы рассмотрим, какие проблемы вынуждают нас воспользоваться этими языковыми конструкциями и варианты их решения. При обсуждении барьеров памяти вкратце рассмотрим модель памяти .NET.

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