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

Алгоритм:

1. Поступить в магистратуру в США.
2. Сделать не кривое резюме.
3. Найти реферал.
4. Подготовится к интервью.
5. Не слиться на интервью и подписать оффер.

И всё!

Теперь про каждый шаг подробнее.

В январе 2015 года Дэвид Брукман, на тот момент кандидат в доктора политологических наук, студент Калифорнийского университета в Беркли, обнаружил что-то странное в исследовании, которое он и его однокурсник Джошуа Калла пытались повторить. Согласно данным эксперимента, полученным аспирантом UCLA Майклом Лакором и опубликованным в Science в декабре прошлого года, геи-агитаторы, работавшие во время предвыборной компании напрямую с жителями различных районов Калифорнии, уже после непродолжительного рассказала о равных правах различных типов брака, в ходе которого они раскрывали собственную сексуальную ориентацию, завоевывали расположение избирателей по данному вопросу.

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

В мае Брукман, Калла и их знакомый ученый Петр Аранов озвучили свои подозрения о несостоятельности доклада в 27 страниц. Девять дней спустя в Science появилась статья с опровержением, слегка озадачившая научные круги и заставившая краснеть тех публичных фигур, которые любят щеголять данными о новых открытиях, не утруждая себя критическими рассуждениями.

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

А точнее эти факты просто таковыми никогда не были.

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

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


В своей новой работе, исследователи продемонстрировали, что деанонимизация возможна и через анализ уже скомпилированных бинарных файлов в отсутствии исходных кодов (видео презентации доклада). В этот раз для исследования использовались исходные коды 600 участников Google Code Jam, которые были скомпилированы в исполняемые файлы, а потом подвергались разбору. Благодаря тому, что задания на соревнованиях были одинаковы для всех, разница файлов заключалась в значительной степени именно в стиле программирования, а не в алгоритме. Изначально, при сборке бинарных файлов отключались оптимизации компилятора и не применялась обфускация исходных кодов. Но, как утверждают авторы работы, некоторые отличительные признаки сохраняются и при применении этих способов сокрытия авторства, снижая точность деанонимизации до 65%.

Представляю вашему вниманию цикл статей по нейросетям, концептуально близкий к серии статей Алексея Редозубова. Для понимания материала рекомендуется ознакомится со всем циклом его статей. По ссылке указана лишь одна статья из цикла, полезная для данного текста.

Механизм управления «толстым клиентом» 1С по OLE дает полный доступ ко всем функциям и данным. Это дает возможность при кастомизации 1С или ее интеграции с внешними системами вообще не использовать встроенный язык программирования и, соответственно, не ограничивать себя его синтаксисом, возможностями и средой исполнения.

Вместо этого можно воспользоваться любым современным языком, имеющим библиотеку для работы с Win32 OLE. Например, JavaScript (Win32 OLE поддерживает Node.JS) или Ruby (нужная библиотека входит в набор стандартных библиотек языка).

Ниже будет описан некоторый практический опыт работы с OLE-интерфейсом на Ruby. Описание не претендует на полноту, отобрано и описано только то, что нужно для простой автоматизации или интеграции на уровне данных: чтение-запись справочников и документов, выполнение запросов.

Смирись, человек 21 века, что твой главный инструмент — это информация, данные, цифры и управление с их помощью. Сегодня мы делимся с вами очень полезным списком литературы о Data Science!

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

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

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

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

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.

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

Но если вы проводите за своим инструментом до 80% рабочего времени, то желательно убедиться, что вы не тратите время впустую и что работа доставляет вам удовольствие. В этой статье я бы хотел немного рассказать про те инструменты, которыми я лично пользуюсь каждый день, и про то, как они улучшают user experience (и, часто, продуктивность) при работе с консолью и с удаленными серверами в частности.

Проблемы ssh

При работе с удаленными серверами по ssh есть много вещей, которые могут фрустрировать, но основных проблем две, и первая из них принципиально неразрешима в рамках ssh:

1. При высоком round-trip latency (>100 ms) пользовательский ввод появляется с ощутимой задержкой, а при использовании мобильного интернета с edge (latency 1000 ms) работа становится подобна пытке
2. При временных проблемах (несколько минут) с доставкой пакетов, соединение может порваться с write failed: broken pipe, причем узнаете вы об этом только при попытке ввода или при использовании настроек вроде keepaliveinterval

Первая проблема неразрешима потому, что ssh by-design является просто транспортом для байтов, и существующие приложения на это поведение расчитывают. Поскольку ssh не пытается интерпретировать этот поток байтов, он не может осуществлять предиктивный ввод. Лично для меня именно эта проблема наиболее актуальна, поскольку мне приходится работать с серверами в европе и США, и во втором случае задержка составляет около 200 мс и является принципиально неустранимой, по крайней мере до изобретения квантовой коммуникации или чего-нибудь подобного. Вторая же проблема проявляется в наших условиях относительно редко, но всё же неприятно переустанавливать все соединения при сбоях сети (и перезапускать упавшие приложения, если они почему-то не были запущены в screen).

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

В продолжение начатых тем на Geektimes:
Часть 3
Часть 2
Часть 1

Продолжу тему, начатую в 3-ей части, но так и не законченную. Сейчас будет рассказ про школы в Германии.
Опять-таки, все, что написано ниже — относится к региону моего проживания, но большинство информации именно из этого поста можно распространить и на всю Германию.

В последние пару дней мне часто приходится отвечать на вопросы, как я нашёл работу в Германии, поэтому я решил объединить весь свой путь (ещё незаконченный) в единый текст и опубликовать здесь, потому как тема мне кажется интересной и актуальной.

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

Вариант с Германией мне подсказала знакомая, которая собирается ехать туда учиться. Погуглил, и действительно — для айтишников (я джава-разработчик) всё очень хорошо. Информации на эту тему в интернете полно, не буду лишний раз дублировать (гуглить по ключевому слову bluecard). Если коротко — достаточно желания работодателя платить вам больше, чем 37 000 евро в год.

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

В тот же день я получил 18 личных сообщений с просьбой скинуть контакты агентов.

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

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

UPDATE 1
UPDATE 2

Думаю, что многим будет полезен мой опыт поиска работы программистом за границей. Тем более что он совершенно отличается от описанного в публикации «Как айтишнику уехать в Германию. Часть 1».

Сразу скажу, что я женат и у меня двое детей 5 и 11 лет. Это я говорю к тому, что требования к условиям переезда для семейного человека выше, чем без детей или вообще без семьи. Например, необходимо учитывать увеличение расходов на минимум 3-к квартиру, коммунальные услуги из расчета на 4 чел, платное образование и его уровень. Также важен транспорт, так как каждый день детям нужно добираться в школу и из школы. Еще одним важным критерием выбора страны для переезда является уровень медицины и экология. И наконец, расходы на содержание семьи из 4 человек на порядок выше чем на двоих и тем более — для одного. Все это ставит довольно жесткую нижнюю планку по зарплате.

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

В общей сложности поиск работы мне занял 9 мес. Страной назначения я выбрал Германию, так как IT там на высоком уровне, огромное количество стартапов, особенно в Берлине, высокий уровень бесплатного образования и сильная медицина. К тому же я более менее знал немецкий.

Данная заметка является дополнением к прочим, уже опубликованным на хабре, статьям, посвященным работе с иностранными заказчиками из России. В последней подобной статье, написанной пользователем mag есть замечательный ссылки и комментарии. Поэтому если вы еще не ознакомились с означенной статьёй, то рекомендую ознакомится. Хотя, моя, заметка озаглавлена как oDesk специфичная, она, также, будет содержать некоторые ссылки и советы, которые могут быть применены и при работе с другими типами-источниками влекущими за собой ВЭД(Внешне Экономическая Деятельность). Но, всё же, если вы собираетесь работать с заказчиками напрямую, т.е. все ваши расчеты будут напрямую, то всё это хорошо описано в предыдущих статьях.

Впервые я столкнулся с Upwork (тогда еще oDesk) в 2011м году, когда брат прислал на них ссылку в скайпе. Я только начинал работать на русских биржах, и подумал — почему бы не попробовать еще и на зарубежной. Но тогда все закончилось ничем. Результаты были слабыми, и, разочаровавшись во фрилансе как таковом, я бросил это дело.

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

Когда я зашел в гости к Робокурс (они учат ребятишек 7-13 лет программированию и робототехнике), то увидел коллекцию раритетных книжек по программированию и вспомнил былое, 286-е без жесткого диска, BASIC из оперативки и прочее.

Я был в восьмом и от одноклассника узнал, что есть «Краевая станция юнных техников» (КСЮТ), где помимо выпиливания лобзиком кордовых авиамоделей есть и инновационный кабинет по программированию. Записался туда. Там были и первые сетевые баталии в NETWARS, и первая порнокартинка, и война за пароль главного администратора. Адекватных книг практически на было, особенно по горячо любимому мной бейсику (только «Программышка» и еще одна розовенькая книга, откуда я узнал, что такое массив и что с ним можно делать).

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

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

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

В данной работе примеры приведены на языке програмиирования C.

Еще три недели назад мой аккаунт в Twitter был практически заброшен.

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

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

Уже довольно долгое время я задаюсь вопросом: «Может ли в наших суровых реалиях жить и развиваться Open Source проект?». Этот вопрос меня периодически тревожит, так как я сам являюсь автором одного такого проекта — WysiBB. Я задавал подобный вопрос на различных ресурсах, были вопросы и на Тостере. Но по сути все сводилось к тому, что в русскоязычном сегменте интернета не работают кнопки «Поддержать проект», «Пожертвовать» и т.д. и развиваться могут только проекты с огромной аудиторией и/или платными функциями.

В чем суть?

Но вот наконец в один прекрасный день, я наткнулся на интересную идею, как можно получать некоторые финансовые вливания в развитие и видеть, какие фичи наиболее востребованы пользователями. Эту идею я увидел на сайте Robomongo(кто не знает, это GUI для MongoDB). И ее суть заключается в следующем: пользователю предоставляется возможность выбрать из списка issues(с джитхаба) наиболее его тревожащую и пожертвовать средства на ее доработку. Когда пользователь делает пожертвование, рейтинг приоритетности этой фичи повышается. Так автор проекта получает средства на свой кошелек и видит какие фичи имеют наивысший приоритет(больше всего пожертвований) и соответственно являются наиболее востребованными. Автор приступает к их разработке в первую очередь, проект развивается, а пользователь получает долгожданную фичу. Мне эта идея понравилась и я решил реализовать подобный механизм на своем проекте, а когда начал работу над этим сервисом, понял что такой сервис может быть полезен не только для меня. Так появился на свет GitFund.