Табличный процессор (речь идет о MS Excel или LibreOffice Calc) — это довольно занятный и универсальный инструмент. Мне часто приходилось (и приходится) пользоваться его широкими возможностями: автоматизированные отчеты, проверка гипотез, прототипирование алгоритмов. Например, я использовал его для решения задач проекта Эйлер, быстрой проверки алгоритмов, реализовал парсер одного прикладного протокола (по работе надо было). Мне нравится наглядность, которую можно добиться в табличном процессоре, а еще мне нравится нестандартное применение всего, чего только возможно. На Хабре уже появлялись интересные статьи на тему нестандартного применения Excel:
«Assembler в 30 строк на Excel»
Чем заняться айтишнику в армии или как я на VBA игры писал
«RPG-игра в рабочей книге Excel»

В этой длинной статье я хочу поделиться своими экспериментами в реактивном программировании с помощью формул табличного процессора. В результате этих экспериментов у меня получился «компьютер» с процессором, памятью, стеком и дисплеем, реализованный внутри LibreOffice Calc при помощи одних только формул (за исключением тактового генератора), который можно программировать на неком подобии ассемблера. Затем, в качестве примера и proof-of-concept, я написал игру «Змейка» и бегущуюползущую строку для этого компьютера.

Я провожу собеседования на тестировщиков. У меня иногда болит голова.

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

Вступление

Давно хотел написать статью про образование в 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, но пытаюсь предложить более-менее универсальную программу).

Автор оригинальной статьи Ali Mese добавил ещё 100 новых бесплатных сервисов. Все 400 потрясающих сервисов доступны здесь. И еще подборку +500 инструментов от 10 марта 2017 г. смотрите здесь.

A. Бесплатные Веб-Сайты + Логотипы + Хостинг + Выставление Счета

• HTML5 UP: Адаптивные шаблоны HTML5 и CSS3.
• Bootswatch: Бесплатные темы для Bootstrap.
• Templated: Коллекция 845 бесплатных шаблонов CSS и HTML5.
• Wordpress.org | Wordpress.com: Бесплатное создание веб-сайта.
• Strikingly.com Domain: Конструктор веб-сайтов.
• Logaster: Онлайн генератор логотипов и элементов фирменного стиля (new).
• Withoomph: Мгновенное создание логотипов (англ.).
• Hipster Logo Generator: Генератор хипстерских логотипов.
• Squarespace Free Logo: Можно скачать бесплатную версию в маленьком разрешении.
• Invoice to me: Бесплатный генератор счета.
• Free Invoice Generator: Альтернативный бесплатный генератор счета.
• Slimvoice: Невероятно простой счет.

Перевод первой части материала с github, обстоятельно объясняющего работу интернета: что именно происходит, когда пользователь набирает в адресной строке google.com?

Кнопка «ввод» возвращается в исходное положение

Для начала отсчёта выберем момент, когда кнопка «ввод» утоплена. В этот момент замыкается контур, отвечающий за эту кнопку. Небольшой ток проходит по логическим контурам клавиатуры. Они сканируют состояние всех переключателей, гасят паразитные электрические импульсы, и преобразовывают нажатие в код клавиши 13. Контроллер кодирует код для передачи в компьютер. Теперь это почти всегда делается через USB или Bluetooth, а раньше в процессе участвовали PS/2 или ADB.

Поиск работы – задача не из простых, особенно в текущих неблагоприятных экономических условиях. Европейский ресурс Tech.eu в честь запуска своего сервиса по поиску работы подготовил список из десяти сайтов, которые помогут вам подыскать себе место под европейским солнцем, если вы, по какой-либо причине, желаете уехать на заработки в ЕС.

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

Buffered Streams

//медленно
InputStream is = new FileInputStream(file);
int val;
while ((val = is.read()) != -1) {
}
//быстро
InputStream is = new BufferedInputStream(new FileInputStream(file));
int val;
while ((val = is.read()) != -1) {
}

Казалось бы — очевидная истина, неправда ли? Но как показал чужой код и опыт собеседования кандидатов, часть разработчиков определенно не понимает в чем преимущество буферизованных стримов. Кто до сих пор не разобрался — метод read() класса FileInputStream:

public native int read() throws IOException;

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

System.arraycopy(src, srcPos, dest, destPos, length);

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

Я уже достаточно много лет занимаюсь разработкой на java и повидал довольно много чужого кода. Как это не странно, но постоянно от одного проекта к другому я вижу одни и те же проблемы. Этот топик — попытка ликбеза в наиболее часто используемых конструкциях языка. Часть описанного — это довольно банальные вещи, тем не менее, как показывает мой опыт, все эти банальности до сих пор актуальны. Надеюсь, статья пригодится многим java программистам. Итак, поехали:

new vs valueOf

//медленно
Integer i = new Integer(100);
Long l = new Long(100);
String s = new String("A");

//быстро
Integer i = Integer.valueOf(100);
Long l = 100L;//это тоже самое что Long.valueOf(100L);
String s = "A";

Старайтесь всегда использовать метод valueOf вместо конструктора в стандартных классах оболочках примитивных типов, кроме случаев, когда вам нужно конкретно выделить память под новое значение. Это связано с тем, что все они, кроме чисел с плавающей точкой, от Byte до Long имеют кеш. По умолчанию этот кеш содержит значения от -128 до 127. Следовательно, если ваше значение попадает в этот диапазон, то значение вернется из кеша. Значение из кеша достается в 3.5 раза быстрее чем при использовании конструктора + экономия памяти. Помимо этого, наиболее часто используемые значения могут также быть закэшированы компилятором и виртуальной машиной. В случае, если ваше приложение очень часто использует целые типы, можно увеличить кеш для Integer через системное свойство «java.lang.Integer.IntegerCache.high», а так же через параметр виртуальной машины -XX:AutoBoxCacheMax=<size>.

Ранее мы уже знакомили вас с переводами статей Chris Bailey, которые он писал по мере развития своего проекта a Year of Productivity — они доступны в нашем блоге в разделе «личная продуктивность».

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

Итак, даем слово Крису!

Мы продолжаем знакомить вас с переводами статей Chris Bailey, где он делится советами, которые извлек во время проекта «a Year of Productivity». Ранее мы публиковали статьи этого автора, они доступны в нашем блоге в разделе «личная продуктивность».

Итак, даем слово Крису!

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

В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.



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

Сейчас занятия закончились, и мы, как и обещали, выкладываем записи лекций, которые перемежаются с мастер-классами, для всех желающих. Понятно, что наш опыт и знания – не 42, но мы надеемся, что они принесут вам пользу.

Александр Александров — «дедушка тестирования» в СНГ делал доклад на юбилейной 15-ой SQA Days в Москве.

Слайды:
www.slideshare.net/VLDCORP/ss-33747358

Видео выступления:

Примечание переводчика: Перевод первой статьи из блога «A Year of Productivity» был благосклонно встречен хабра-сообществом, и меня попросили перевести еще несколько статей из этого блога. Приведенная ниже статья — самая большая и самая близкая к практике, её перевод затянулся у меня на несколько месяцев. Как и прошлый раз рекомендую читать комфортными порциями, записывая (или копируя куда-нибудь) советы, которые хочется попробовать применить на практике.

«Хаки» времени

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

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

Для начала вот несколько моих любимых приемов по тому как:
-  получить больше времени;
-  тратить время на правильные вещи.

При разработке приложений я заметил, что каждый раз, когда мне приходилось сталкиваться с решением похожих задач (реализовывать работу с http, json, multithreading и т.п.), приходилось делать одну и туже роботу, причем на это уходило много времени. Поначалу это было не критично, но в больших проектах занимало слишком много времени. Чтобы сэкономить свое и ваше время, решил написать универсальное решение для этих задач, которым и хочу поделиться с сообществом.

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



Препарируем вот этот исходник с точки зрения ученика 5-го «Б» Васи Пупкина, прочитавшего книжку по основам javascript, и страстно желающего получше запутаться в полученных знаниях.

У нас в отделе четыре Scrum-команды. Спринты, таймбоксинг, митинги, демо, Product Owner, заказчик и т.д. С годами сформулировался список основных ценностей:

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

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

Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.

Совсем недавно, на собеседовании в Яндексе, мне довелось обсуждать организацию Rest-взаимодействия в Android-приложениях. В ходе обсуждения всплыл вопрос – почему из трех паттернов, предложенных на Google IO 2010 Virgil Dobjanschi, первый используется существенно чаще двух других. Вопрос меня заинтересовал.

Поскольку тема обсуждения достаточно узкоспециализированная, я с позволения читателей пропущу слова о том, насколько правильная архитектура Rest-взаимодействия важна в Android-приложениях и как часто Android-разработчики сталкиваются с подобными задачами.

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

Я хочу достичь следующих целей при использовании системы:

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

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

• Мой опыт по описанному вопросу
• Проблемы запоминания
• Теоретическое разрешение проблем
• Практическое разрешение проблем с Evernote
• Практическое разрешение проблем с Anki

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

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

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