UPDATE 2018-02-04: Еще одна мудрость со временем накипела: если хочется полной свободы выбора компаний любого размера, то лучше сразу говорить, что вы нашли хорошую компанию по релокейту и всё, что требуется, это финансовая поддержка. Деньги тут есть (особенно у страртапов), а времени — нет.

UPDATE 2017-03-19: По опыту двоих приятелей из Берлина (из России и Коста-Рики) могу обнадёжить, голубую карту могут сначала не дать, а через полгода таки дать прямо в Германии. Немцы тоже люди и их чиновники тоже умеют и искренне заблуждаться, и нарочно упираться.

UPDATE 2017-01-08: год спустя поимел опыт поиска и найма фронтендеров для двух компаний. Заявляю, что хорошего кандидата, подписавшего договор, готовы ждать месяц-два. Меня один средних размеров стартап согласился ждать 4 месяца после очного интервью. Так что заехать себя показать, а потом начать удаленно и через пару месяцев перебраться — вообще шоколад.

UPDATE 2016-09-02: полгода спустя немного подросла нижняя планка з/п для голубой карты, а остальное пока в силе.

UPDATE: по просьбе chilicoder добавляю ремарку: «автор смог переехать и найти работу даже без признанного диплома».

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

Зона комфорта — это зло. Хоть и приятное, даже очень. Но зло. Особенно, если речь идет о саморазвитии и изучении языков. Если каждый день в работе использовать довольно простые лексику и грамматику с минимальными изменениями, есть большая вероятность, что вы начнете забывать всякие там Conditionals или Future Perfect. Конечно же, нужно поддерживать язык на должном уровне и развивать его, поэтому мы попросили наших преподавателей поделиться книгами, которые им в этом помогают. Так что готовьтесь к подборке для высоких уровней и не только!

Произношение

Ship or Sheep? An Intermediate Pronunciation Course

В этом пособии вы найдете неплохой тест, который покажет ваши слабые стороны (всякие там “сри” или “фри”). Даже если ничего подобного не обнаружится, учебник стоит пройти от начала до конца, и вот почему:

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

Вы скажите, что уже есть всякие там разговорники и даже волшебные наушники, как рыбка из “Автостопом по галактике”, которые переводят все на лету. Это правда, но вот качество таких переводов пока все также на уровне Google Translate или Prompt пятнадцатилетней давности. В смысле, что машинный перевод пока еще не очень и его нужно фильтровать и проверять, а общаться нужно уже сейчас.

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

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

В Австралии опасно. Не так, чтобы всё живое хотело вас убить, но близко. Смертей десятки в год, что близко не лежало в сравнении с ДТП, но зато они очень, скажем так, изобретательные. Например, к воде вообще нельзя подходить — там, в зависимости от водоёма, крокодилы, ядовитые кубомедузы, акулы и змеи. Благодаря одному немецкому туристу, последние слова которого были «Да нет тут никаких крокодилов», знаки об их наличии по шоссе Стюарта теперь на двух языках. А благодаря одной женщине, решившей искупаться во время менструации, мы теперь знаем, что акулы умеют подниматься вверх по течению ручья на 2 километра. Хворост около трассы для биваков туристов собирают строго гиды — отлучаться с асфальта опасно для жизни, потому что в топ-20 самых ядовитых змей мира всего 2 строки принадлежат неместным. К огромному неудовольствию австралийцев.


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

А ещё Австралия постоянно либо затоплена, либо горит, либо находится в короткой передышке между этими состояниями. Но давайте начну с самого начала. Сначала мы оказались в Nowhere Land Северной территории.

Екатерина Малахова, редактор-фрилансер, специально для блога Нетологии адаптировала статью Beau Carnes об основных типах структур данных.

«Плохие программисты думают о коде. Хорошие программисты думают о структурах данных и их взаимосвязях», — Линус Торвальдс, создатель Linux.

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

В этой статье я покажу вам 10 самых распространенных структур данных.

Инструменты – средство усиления вашего таланта. Чем они лучше и чем лучше вы ими владеете, тем больше вы сможете сделать.
Энди Хант и Дейв Томас «Программист-прагматик. Путь от подмастерья к мастеру»

DISCLAIMER: это не заказная и совершенно не проплаченная статья (JetBrains, я ни на что не намекаюJ). Здесь представлены лишь возможности популярного расширения для VisualStudio (а иногда и аналогичные возможности самой студии), которые я лично использую в повседневной деятельности.

В начале 1960-х Ричард Фейнман давал несколько лекций для студентов, позже собранных в книгу "Фейнмановские лекции по физике". В книгу не вошла лекция по планетарному движению, но найденные позднее заметки позволили Дэвиду Гудштейну, коллеге Фейнмана, написать о ней книгу: "Потерянная лекция Фейнмана" [David Goodstein, Feynman’s Lost Lecture]. Цитата из книги, опубликованной в номере журнала Caltech’s Engineering & Science 1996 года:

Фейнман был великим учителем. Он гордился способностью придумывать способы объяснять самые глубокие идеи начинающим студентам. Однажды я сказал ему: «Дик, объясни мне так, чтобы я понял, почему частицы с полуцелым спином подчиняются статистике Ферми-Дирака». Фейнман сказал: «Я подготовлю лекцию для первокурсников на эту тему». Но через несколько дней он вернулся и заявил: «Я не смог. Я не смог низвести это до уровня первокурсников. Это значит, что на самом деле мы этого не понимаем».

Невозможно, просто взять и вникнуть в этот глубокий смысл, изучая События (event) в просторах базового и, на первый взгляд, бесконечного C#.

Когда я изучал События (не в рамках .NET!), потратил много сил, чтобы, наконец-то, разобраться, как они устроены и должны конструироваться. Поэтому, я решил опубликовать свою методику понимания структуры пользовательского события, коим представляется ключевое слово event в С#.
Не буду цитировать и без того замученную MSDN, а постараюсь объяснить понятно и доступно.

Управляемая память в .Net поделена на стек и несколько хипов. Самые важные из хипов – это обычная (эфемерная) куча и LOH. Эфемерная куча – это то место, где живут все обычные объекты. LOH – это то место где живут большие (больше 85000 байт) объекты.

LOH обладает некоторыми особенностями:

• Объекты в LOH никогда не перемещаются
• LOH только растет и никогда не уменьшается (т.е. если объект собран сборщиком мусора, размер LOH все равно остается неизменным)
• Хип LOH освобождается только тогда, когда LOH полностью пуст

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

• Память в LOH может оказаться фрагментированной. Т.е. происходит то, с чем так боролись в unmanaged мире: в какой-то момент у вас может быть 10Mb свободной памяти, но вы не сможете выделить память под объект размером 1Mb
• Если вы однажды выделили память под большой объект, а потом используете только маленькие, то вы фактически лишаете себя большого куска памяти. При чем, если у вас в LOH был список или хэш-таблица размером N, а вы добавили в него один элемент, то список реаллоцируется и растет в два раза, сответственно размер LOH составит как минимум 3*N (N – исходные данные, 2N – копия данных и резерв под новый размер). Следующий рост потребует в LOH непрерывный кусок памяти размером в 4*N, а так как такого куска в LOH у нас нет (есть только N), его придется позаимствовать из адресного пространства процесса. В итоге размер LOH вырастет до 7*N, и так далее.

Если вспомнить, что LOH аллоцируется кусками по 16Mb, то все происходящее покажется еще более разрушительными. С первым следствием можно бороться аккуратно переиспользуя объекты. Со вторым — не используя большие объекты. Получается как-то не очень, особенно если с большими коллекциями работать все-таки хочется. Посмотрим, что как можно решить эту проблему.