Вступление

Давно хотел написать статью про образование в Computer Science, но руки не доходили. Решил все-таки это наконец сделать. Итак, о чем пойдет речь? Речь о том, что из себя представляет диплом MSc Computer Science топовых университетов США (во всех подробностях, включая основные курсы, книги и проекты) и как ему соответствовать.

Почему именно MSc? Это — некая развилка: с одной стороны после MSc — вы уже готовый к жизни инженер (да, речь идет о инженерной подготовке, как мне кажется это самое больное место в нашей системе образования), с другой — можно спокойно идти по пути PhD. Как известно, в PhD программу можно попасть и не особо умея программировать — особенно это касается теоретического Computer Science. С другой стороны найти работу программиста тоже дело не очень сложное, и часто не требует мощного образования. Но достигнув уровня MSc — вы получаете возможность разбираться как во всех новый идеях в Computer Science, так и возможность их воплотить в практику. То есть с одной стороны круто разобраться в каком-нибудь deep learning и сделать в нем что-то новое, а также взять и написать свою операционную систему (кто так сделал?). Причем вы не зажаты в рамки узкой специализации (если конечно продолжаете учиться). То есть вы теперь — универсальный солдат, готовый на все.

Надеюсь что эта статья будет полезна:
1. Студентам, которые хотят соответствовать высоким стандартам топ вузов США, или собирающиеся туда в аспирантуру по Computer Science
2. Профессионалам, которые хотят закрыть «дыры» и пробелы
3. Может кто-то из преподавателей возьмет на заметку для своих курсов.
4. Студентам, аспирантам американских вузов — хотелось бы тоже получить фидбэк, особенно касается последних трендов в образовании

Что же здесь будет написано? Минимум философии и общих мыслей: конкретная программа undergraduate и graduate курсов, конечно из дисциплин наиболее мне близких. Все курсы были лично прочувствованы на собственной шкуре, по этому и пишу. (Я пытался записаться на все интересные курсы, которые были, но мой основной упор — системное программирование, базы данных и искусственный интеллект. Отсюда конечно некий bias, но пытаюсь предложить более-менее универсальную программу).

Несколько лет назад мы – авторы данного материала – изрядно покопавшись в патентах, дневниках и лекциях Н.Теслы (благо, образование позволяло) пришли к выводу, что пресловутая Башня Тесла по передаче энергии не «фейк», а вполне рабочая конструкция.

В результате нескольких лет исследований, размышлений, изучения первоисточников, сопоставления данных, формирования и отсеивания гипотез и т.п. – появилась красивая и, по сути, простая модель, которая строго вписалась в классическую физику и была подтверждена численным моделированием в пакете Ansoft HFSS. С момента начала проекта, мы провели некоторое количество дискуссий в различных сообществах, где от нас требовали «статью для технарей» — в результате появился данный материал.

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

От переводчика: Это деcятая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

В прошлой статье о локализации приложений Node.js мы узнали, как использовать модуль i18n-abide в нашем коде. Наша работа, как программистов, фактически закончилась на том, что мы обернули строки в шаблонах и коде приложения в вызовы gettext(). Но работа по локализации и переводу приложения только начинается.

Инструментарий

Инструментарий локализации команды Mozilla Persona совместим с теми инструментами, которые используются в остальном сообществе Mozilla, и при этом сохраняет преимущества в дружественности и гибкости, присущие Node.

Проекту Mozilla уже почти 15 лет, и наша команда локализаторов и переводчиков одна из самых больших (и клёвых) в мире Open Source. Поэтому у нас широко используются давно привычные, можно даже сказать старинные и причудливые инструменты.

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

На прошедшем неделю назад чемпионате мира по командному программированию ACM ICPC 2013 было 11 задач, одну из которых за отведённое время не смогла решить правильно ни одна из команд.

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

В этом году на ACM ICPC был 21 аналитик из Швеции, Нидерландов, США, Словакии, Беларуси и России. И 10 из них были из Яндекса. Все они в разные годы были призёрами ICPC. Специально для Хабра они разобрали все задания чемпионата.

По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?

Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.

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

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

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

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

Привет!
Прошлые два обзора полезных книг за 2010 и 2011 год собрали просто адовое количество закладок, поэтому я продолжу. Прошел ещё год, ещё около 250 прочитанных книг – и вот самые интересные под катом.

Кто сказал, что слоны не умеют танцевать? Возрождение корпорации IBM: взгляд изнутри (Герстнер Луис)

Отличная книга про то, как удалось восстановить IBM. То, что со стороны выглядело как бессистемное перемещение активов и последовательность приказов без особого смысла, через несколько лет начало складываться в единую систему.

Догнать зайца (Стивен Спир)

Отличная книга про дебаг производственных процессов. Одна из основных вещей – то, что все серьёзные проблемы возникают из-за сочетания некритичных багов. Есть примеры из американской ядерной программы, NASA и т.п. Я предлагаю прямо сейчас пойти и прочитать описание железнодорожного крушения на Каменской: один не отчитался, второй не проверил тормоза, третий зажал тангенту, четвёртый сорвал стоп-кран. Результат — катастрофа.

AngularJs – великолепный фреймворк для разработки web-приложений. Разработка бизнес-логики приложения полностью отделена от сопутствующей суеты вокруг DOM. Angular модульный – это замечательно, но так же является источником проблемы. Количество модулей быстро растёт. И если директивы ещё можно упаковывать в отдельные пакеты типа angular-ui, то с контроллёрами бизнес-логики всё сложнее. Всё становится ещё хуже, когда требования безопасности в принципе запрещают загрузку на клиента контроллёров с бизнес-логикой, которые недоступны текущему пользователю. При развитой ролевой системе доступа к приложению масштаб проблемы становится очевиден.

Уже давно существует целое сообщество любителей-разработчиков, которые занимаются программированием летающих роботов. Они устраивают периодические конференции и сходки. Но в чем же особенность данного сообщества, спросите Вы? дело в том, что программирование квадрокоптеров осуществляется на Javascript на платформе NodeJS. Среди разработчиков большой популярностью пользуется всем уже известный ArDrone Parrot, который уже не раз освещался на страницах Хабра.



Подробности под катом.

После запуска в какой-то мере скандального сервиса MEGA разговоры о его защищенности немного побурлили и затихли. На сегодняшний день сервис живет своей жизнью и его никто даже не поломал. Из всех разговоров почему-то был упущен термин «User Controlled Encryption» (UCE, или Контролируемая пользователем криптография), которой кичится MEGA. Под словом «упущен» я подразумеваю тот факт, что мы не рассмотрели все возможности, которые дает нам криптографический движок, выполняющийся в JavaScript на стороне клиента.

Конечно, сам сервис MEGA под этим подразумевает всего лишь то, что ключи шифрования не хранятся на сервере, а вся их криптография выполняется в контексте браузера. При этом после запуска сервиса было много разговоров о том, что в нем используются нестойкие криптографические алгоритмы и что вообще все плохо и мы все умрем, а наши файлы прочитает ФСБ. Это подтолкнуло меня на мысль расширить понятие «UCE» и действительно взять криптографию под свой контроль, а именно — заменить или дополнить некоторые механизмы обеспечения безопасности сервиса.

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

Я удивлен, что эта техника упоминалась на Хабре только один раз и вскользь — если верить поиску, конечно.
Меня не покидает ощущение, что на самом деле все про это знают, но я всё же расскажу.

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

Делается это несложно — нужно всего-то добавить пару мета-тегов в head:

<link rel="prefetch" href="NEXT PAGE URI" />
<link rel="prerender" href="NEXT PAGE URI" />

Теперь подробнее про ограничения и нюансы.

В России приступили к тестированию отечественного фаервола, первый город для тестов который был выбран — Волгоград.

В нем были заблокированы сайты: Vk.com, Youtube.com

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

О чем это

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

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

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

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