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

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

Введение

Зачем это вообще надо? В науке и около нее очень часто возникает задача предсказания какого-то неизвестного параметра объекта исходя из известных параметров этого объекта (предикторов) и большого набора похожих объектов, так называемой учебной выборки. Пример. Вот мы выбираем на базаре яблоко. Его можно описать такими предикторами: красность, вес, количество червяков. Но как потребителей нас интересует вкус, измеренный в попугаях по пятибалльной шкале. Из жизненного опыта нам известно, что вкус с приличной точностью равен 5*красность+2*вес-7*количество червяков. Вот про поиск такого рода зависимостей мы и побеседуем. Чтобы обучение пошло легче, попробуем предсказать вес девушки исходя из ее 90/60/90 и роста.

Творческая беседа Дэна Шиппера, кофаундера Firefly и Джейсона Фрайда, кофаундера 37signals привела автора статьи к занятным выводам о том, как и кому продавать ПО. Надеемся, и вам, Хабражители, принесет пользу.

Переведено компанией-локализатором Alconost

Это перевод нашумевшей статьи с TechCrunch от Джеймса Альтушера — инвестора, программиста, автора статей и немного предпринимателя. Его последние книги: Я был слеп, но теперь я вижу и 40 альтернатив колледжу. Читайте его в Twitter @jaltucher.

Люди читают TechCrunch потому, что они хотят что-то создать, они не желают следовать приказам всю жизнь и хотят финансовой свободы. Давайте начистоту. Эти три пункта кажутся притягательными. Да благословит Вас Бог. Надеюсь, что когда Вы их обретете, Вы сможете сохранить их. Большинству людей (например, МНЕ), нужно просто немного покататься на американских горках, потому что мы тупые. Но некоторые люди умные.

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

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

На первый взгляд это может показаться тривиальной задачей, не так ли? Если сторонами треугольника являются x и y, то, формально, формулой для вычисления гипотенузы будет:

sqrt(x*x + y*y)

Это работает теоретически, но на практике данный подход может приводить к ошибке. Если значение x достаточно велико, то вычисление x*x может привести к переполнению типа данных (ни один тип данных от этого не застрахован, если не рассматривать длинную арифметику), и результатом вычислений будет бесконечность.

Еще летом я запланировал эксперимент и написал статью Использование UML для эксперимента по эволюционной систематике прокариот, и косвенно о психологии ученых. Результаты по грубой обработки уже были готовы к концу лета (спасибо, mktums за помощь ).

Вот теперь образовалась пауза, и я добил эту тему, и представляю результаты.

Я заметил, что самые взрослые и опытные разработчики, с которыми мне доводилось работать, входят в число тех, кто чаще всего говорит «Я не понимаю», когда они выслушивают техническое объяснение. Так бывало с коллегами в Fog Creek и Khan Academy.

С одной стороны, это противоречит здравому смыслу. Разве не должны «сеньоры» уже знать всё? Но это вполне логично. Те, кто больше других уверены в своих способностях, являются также людьми, способными признать, что не вникли полностью в суть чего-либо. Молодые разработчики допускают, что их непонимание — их же собственная вина. Они не хотят отвлекать остальных из-за своих воображаемых промашек.

Молодым разработчикам стоит попробовать осознать, насколько часты непонимания вопроса. В большинстве стеков технологий уже пройдена черта, после которой удержать в голове весь код невозможно, особенно, в компаниях, которые набирают сотрудников. И если эта граница пересечена, всё чаще можно слышать о новом фреймворке рендеринга Javascript, или последнем конвейере MapReduce, или баге в скрипте развертывания, или плане нового шаблона кэширования, а тихий голосочек в вашей голове уже хочет сказать: «Постойте… мне это не понятно.»

Если и есть что-то неизменное с того дня, когда я начал писать код и по сегодняшний день (а я пишу уже дней 500). Так это то, что незнание с чего начать — невероятно пугает. Я остро помню панику изучения HTML, когда я понятия не имел, как заставить мои div-ы располагаться там, где я хотел. Я понимал концепцию сетки, но реализация никак мне не давалась в течение нескольких дней.

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

Книги, которые должен прочитать Java программист: от новичка до профессионала

[Примечание переводчика: термины градации «профессионализма» оставлены англоязычные в связи с трудностью их адекватного перевода на русский и несовпадением с привычными Junior-Middle-Senior-Lead. Перевод достаточно вольный — если знаний языка хватает, то лучше читать оригинал, как и советует автор. Оба языка для меня не родные, так что про ошибки сообщайте в личку — исправим. Здесь и далее в квадратных скобках примечания переводчика]

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

Я уже описывал моё коротенькое юношеское баловство с незаконной стороной информатики в её виде на конец 1980-ых. Но было ли это преступлением? Был ли я настоящим преступником? Не думаю. Говоря начистоту, я не был достаточно одарен, чтобы представлять хоть какую-нибудь угрозу, да и сейчас не представляю.

Есть две классические книги, описывающие деятельность обладавших уникальным талантом хакеров в конце 80-ых, талантом, который поднимал их опасность до признания в качестве криминальной угрозы.

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

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

Примечание редактора: Джеймс Альтухер — инвестор, программист, автор и предприниматель. Он инвестировал в 25 стартапов и написал 10 книг. Последними вышли книги «Я был слеп, но сейчас прозрел» и «40 альтернатив колледжу».


Я был одинок и хотел денег. Я жил в однокомнатном номере в Астории, район Куинс Нью-Йорка в 1995-м и не знал никого в округе. Я писал свой номер телефона на двухдолларовых купюрах, которые оставлял на чай официанткам, но ни одна мне не звонила. В Астории жили одни греки, а те предпочитали свою тусовку. Никто не заговаривал со мной. Я мог наворачивать мили по Астории в надежде найти собеседника.

Выходные были хуже всего. Я скучал по друзьям на работе. Музей кинематографии находился совсем рядом, и я ходил туда посмотреть всякие инди-фильмы. Помню две вещи: ретроспектива Хэла Хартли была великолепна, а коллекция свитеров Билла Косби, которые тот носил на своих шоу 80-х, выставлялась на заметном месте. Женщина-билетер не любила меня, так как я всегда заходил бесплатно по карточке работника HBO.



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

«1. Держите сервера за границей»
(с) 9,5 правил ведения безопасного бизнеса в России

Вводная часть.

Мы — маленькая компания из 10 сотрудников, половина из которых периодически работает удаленно.
Что мы имели изначально: сервер с Windows и терминальным доступом, который стоял в офисе. У всех пользователей были ноутбуки. Никакой особо конфиденциальной информации у нас нет, за исключением важной для бизнеса информации.
В один прекрасный момент меня окончательно «добила» паранойя и было принято решение вынести сервер за пределы офиса.

Начав писать комментарий к посту «Гадание на кофейной гуще, или каким будет IT через 5 лет?», я понял, что пришло время написать отдельный пост о своих взглядах на будущее ИТ.

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

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

Например, 2007-12 гг. — это время массового распространения социальных сетей и бурного роста всевозможных стартапов, практического утверждения в период кризиса идеи о том, что ИТ и инновации вообще — это будущее, что множество планктоноподобных направлений будет избавляться от персонала, а ИТ прирастать. (Отрицательной стороной этого стало появление инвесторов-дилетантов, не особо разбирающихся в сути конкретного ИТ-проекта и потому по ходу раздувающих пузыри.)

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

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

Cloud9

«Это Google Docs, только для кода» — так говорят о проекте. Облачный сервис вырос из Mozilla Bespin. Основные фишки: SSH, drag-and-drop и возможность разработки оффлайн.

Грязный

Давайте вместе поразмыслим — что же такое чистый код, и что такое код грязный? Или, как говорят американцы – «hairy code», т.е. волосатый?

Чем чистый код отличается от грязного – или, как говорят в этих наших интернетах, от «говнокода»? Да и нужен ли он вообще, этот чистый код?


Давайте сначала разберёмся с определениями.

Мне кажется, что дать чёткого определения «чистому» коду просто невозможно. Отчасти это – как с красотой: смотришь на картину, или там скульптуру – и видишь: да, красива. Или, наоборот, уродлива.

— … Тут я даю ему по морд… Нет, бить нельзя!
— В том-то и дело, что бить нельзя, — лицемерно вздохнул Паниковский. — Бендер не позволяет.
И.Ильф, Е.Петров. Золотой теленок.

Мозголомная Брага жила в прозрачном сосуде и была такая
крепкая, что даже ужас. Она не то что из живота — прямо изо рта
бросилась в голову и стала кидаться там из стороны в сторону,
ломая умственные подпорки и укрепы.
М.Успенский. Там, где нас нет.

Пожалуй каждый, кто впервые приступает к изучению Erlang, ощущает себя в положении Шуры Балаганова, которому запрещено было применение единственного доступного и понятного метода: «бить нельзя...». В Erlang отсутствуют такие привычные для большинства современных языков понятия, как повторное присвоение переменной и, соответственно, накопление результата в одной переменной. (Справедливости ради следует отметить, что поведение типа «глобальная многократно меняющаяся переменная» в Erlang все же можно реализовать. Для этого в каждом процессе имеется словарь хешей, хранящий определяемые программистом пары ключ — значение. Имеются встроенные функции put(Key, Value), get(Key) и еще несколько вспомогательных функций. Но использование такого словаря в приложениях считается плохим стилем и рекомендуется только в исключительных случаях (http://www.erlang.org/doc/man/erlang.html\#put-2)). Как следствие, итерации в цикле невозможно реализовать с помощью привычного наращивания значений итерационной переменной. Накопление результата осуществляется только через рекурсию, а организация циклов — через хвостовую рекурсию. (Конечно, и итерации, и накопление результата в цикле можно реализовать через библиотечные функции для списков lists:foreach(Function, List), lists:foldl(Function, StartValue, List), lists:foldr(Function, StartValue, List) (http://www.erlang.org/doc/man/lists.html) и их аналоги для наборов (http://www.erlang.org/doc/man/sets.html, http://www.erlang.org/doc/man/ordsets.html, http://www.erlang.org/doc/man/gb_sets.html) и массивов (http://www.erlang.org/doc/man/array.html). Но наша цель — научиться писать циклы, а не использовать готовые решения, поэтому здесь мы воздержимся от употребления подобных библиотек).

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

В житии святого Антония Великого есть рассказ об одном из его учеников. Ученик стоял в храме и слушал, как святой Антоний читал Псалтырь. Как только прозвучал первый стих первого псалма:
Блажен муж, который не ходит на совет нечестивых...
ученик вышел из храма. С тех пор его никто не видел почти 30 лет, а когда он вновь появился в храме, Антоний Великий спросил, почему он оставил их так надолго и куда исчез. Ученик ответил: «отче, я услышал слова псалма, и удалился в пустыню, чтобы постараться выполнить то, о чем говорится в этих словах, т.е. не ходить на совет нечестивых мыслей». Другими словами, он усвоил практический урок этих слов, и теперь пришел чтобы читать дальше. К сожалению, у нас нет такого резерва времени, да и цели наши не столь возвышенны. Но основной концепт можно перенять.
Мы рассмотрим две стандартные комбинаторные задачи:

1. поиск всех возможных перестановок (permutations) из данного множества по N элементов
2. поиск всех возможных сочетаний (combinations) из данного множества по N элементов

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

Внутри у среднего банкомата лежит от 1 до 3 миллионов рублей. Они разложены по 4 кассетам, в каждой из которых – купюры своего номинала. Замена кассет похожа на замену картриджей в принтере: модуль вынимается (и неважно, сколько там осталось денег — инкассаторы этого даже не знают по правилам безопасности), а на его место вставляется другой модуль точно по стрелке, указывающей, какой стороной и как это делать.

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

Это первая часть перевода статьи What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text

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

Эта статья о кодировках и наборах символов.

Это вторая часть перевода статьи What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text, первая часть — тут.

Мой документ – полная чушь в любой кодировке!

Если последовательность бит не выглядит разумной(с точки зрения человека), то это случай, когда документ скорее всего был неверно сконвертирован в определенный момент. К примеру мы берем текст ÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔǵÇ≠ǻǢ, и, не придумав ничего лучше, сохраняем его в UTF-8. Текстовый редактор предположил, что он правильно прочитал текст с кодировкой Mac Roman и теперь его надо сохранить в другой кодировке. В конце концов, все эти символы валидны в Unicode. В смысле, в Unicode есть пункт для É, для G, и так далее. Так что мы просто сохраняем его в UTF-8:

11000011 10001001 01000111 11000011 10001001 11000011 10101100 11000011 10001001 01010010 11000011 10000101 01011011 11000011 10001001 01100110 11000011 10001001 01000010 11000011 10001001 11000011 10101100 11000011 10001001 01001111 11000011 10000111 11000011 10010101 11000011 10101100 11000011 10010100 11000011 10000111 11000010 10110101 11000011 10000111 11100010 10001001 10100000 11000011 10000111 11000010 10111011 11000011 10000111 11000010 10100010