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

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

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

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

Здравствуй, Хабр. Меня зовут Виталий Котов, я работаю в отделе тестирования компании Badoo. Я пишу много UI-автотестов, но ещё больше работаю с теми, кто занимается этим не так давно и ещё не успел наступить на все грабли.

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

Статья будет интересна начинающим авторам UI-тестов, но и старожилы в этой теме наверняка узнают что-то новое, либо просто улыбнутся, вспомнив себя «в молодости». :)

Поехали!

Поднимите голову и посмотрите на что-нибудь равномерно окрашенное, на какой-то светлый фон (на снег, на небо без солнца). Если перед глазами вдруг начали медленно проплывать вот такие примерно штуки:



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

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

UPD: в этом посте отражено субъективное мнение автора в 2018-ом году. Сейчас я работаю над своим проектом в сфере обучения облачным технологиям.

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

Развалившись в гамаке, на берегу острова Бора Бора, ты неспешно рисуешь скетч или отрабатываешь навыки js-ниндзя.

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

Может так и бывает, но уж точно не у меня. Поэтому, проработав 12 лет на фрилансе (около 11,000 часов), внезапно, я задумался — а что дальше? А почему я топчусь на месте то. Пусть у единиц, но получается расти дальше, расширять базу клиентов, основывать компании, интересно жить в конце концов.

Поэтому этот пост с СЕО-шным названием будет именно о том, что не так во фрилансе со «своей колокольни». Во-первых самоанализа ради. А во-вторых для того парня из офиса, который мылится работать на себя, да все никак… За 12 лет много опыта накопилось, есть чем поделиться. Много примеров из опыта.

Когда только Dropbox запустился, один пользователь на Hacker News прокомментировал, что реализовать его можно несколькими bash-скриптами с помощью FTP и Git. Сейчас такого сказать никак нельзя, это крупное облачное файловое хранилище с миллиардами новых файлов каждый день, которые не просто как-то хранятся в базе данных, а так, что любую базу можно восстановить на любую точку в течение последних шесть дней.

Под катом расшифровка доклада Славы Бахмутова (m0sth8) на Highload++ 2017, о том, как развивались базы данных в Dropbox и как они устроены сейчас.


О спикере: Слава Бахмутов — site reliability engineer в команде Dropbox, очень любит Go и иногда появляется в подкасте golangshow.com.

Содержание

• Кратко об архитектуре Dropbox
• История развития баз данных и как устроена текущая архитектура Dropbox
• Простейшие операции над базами данных (фейловеры, бэкапы, клоны, промоушены)
• Автоматизация — что управляет всеми базами данных и запускает операции
• Мониторинг
• Тестирование, стейджинг и DRT

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

Собеседование — это экзамен

Ведущий — строгий учитель, а кандидат — студент. Классический сеттинг. Обычно проходит так. Спросили откуда ты, что ты, и потом пошло техническое собеседование.

Начинается с простых вопросов на раскачку, примерно таких:

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


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

Вот один из самых страшных экранов для тех, кто переезжает с физического железа:



Шучу. Главный страх админа при переводе инфраструктуры в облако — это потеря собственной важности. Почти все боятся, что перестанут быть незаменимыми. Это иллюзия. Важно не знание технологий, а знание компании и её устройства. Технологии быстро доучиваются.

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

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

Если вы читали на ночь Олифера «Компьютерные сети» или книгу с таким же названием Таненбаума, то проблем не будет почти точно. Это когда-то было классикой админов в свитерах, а теперь стало классикой админов в галстуках.

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

Я никогда так не думал. Я любил офис и эту спокойную сосредоточенность рабочего места. Думал, никогда со мной не случится. Но удалёнка случилась. Уже два года. И я пишу сюда, на любимый Хабр, свой очень субъективный пост — просто, чтобы была вторая сторона этой, как оказалось, тянущей шею медали.


Adme.ru

Моя история началась где-то в октябре 2016 года когда в голове поселилась мысль «А почему бы не попробовать работать за рубежом?». Сначала были простые интервью с аутсорсинг компаниями из Англии. Было очень много вакансий с описанием «возможны частые командировки в Америку» но место работы находилось все также в Москве. Да, предлагали хорошие деньги, но душа просила переезда. Скажу честно, если бы меня спросили пару лет назад «Кем вы видите себя через 3 года?», я бы никогда не ответил «Буду работать в Тайланде по рабочей визе». После успешного прохождения интервью и получения офера 15 июня 2017 года я сел в самолет Москва — Бангкок с билетом в один конец. Для меня это был первый опыт переезда в другую страну и в данной статье я хочу рассказать про сложности переезда, возможности которые вам открываются. И в конечном итоге главная цель — вдохновить! Добро пожаловать под кат дорогой читатель.

Готовы погрузиться с головой в дивный мир программирования? Хотите узнать как непредсказуемо могут повести себя несколько простых строк кода?

Если ваш ответ "Да!" — добро пожаловать под кат.

Вас будут ждать несколько занимательных задачек на С или С++.

Правильный ответ с объяснением всегда будет спрятан под спойлером.

Удачи!

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

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

В этой статье 22 страны сравниваются по следующим параметрам:

1. Зарплаты программистов
2. Налоги
3. Стоимость жизни (аренда жилья, коммунальные услуги, продукты, транспортные расходы)
4. Развитость рынка IT
5. Социальное обеспечение

Disclaimer: Эту статью я начал писать достаточно давно и закончил только сейчас, так как не было времени. За это время было опубликовано еще 2 аналогичные статьи: вот эта и вот эта. Часть информации в статье повторяет информацию из этих двух статей. Однако, так как всё описанное в статье я рассматриваю через призму собственного опыта, я решил оставить ее без изменений.

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

Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.

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

Java — очень распространённая платформа, на ней пишут очень разные вещи, начиная от Big Data, заканчивая микросервисами, монолитами, enterprise и прочим. И, как правило, всё это развёртывают на Linux серверах. При этом, соответственно, те люди, которые пишут на Java, зачастую делают это совсем на других операционных системах. Там они:

• пишут код;
  
• отлаживают, тестируют;
  
• после этого упаковывают в jar;
  
• отправляют на Linux, и оно работает.
  

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



С другой стороны, есть те, кто занимается администрированием серверов, на их сервера устанавливают JVM, отправляют jar и war-файлы, а с точки зрения мира Linux все это:

• чужеродное;
  
• проприетарное;
  
• собирается не из исходников;
  
• поставляется какими-то jar-архивами;
  
• «отъедает» всю память на сервере;
  
• вообще, ведёт себя не по-человечески.
  

Цель доклада Алексея Рагозина на Highload++, расшифровка которого идет далее, была в том, чтобы рассказать особенности Java для «линуксоидов» и, соответственно, Linux — Java-разработчикам.

Какие инструменты нужны тестировщику? Об этом мы сегодня порассуждаем в этой статье, в основе которой — доклад Юлии Атлыгиной с прошлого Heisenbug. Видеозапись доклада доступна по ссылке.

Собеседования для разработчиков программного обеспечения часто включают в себя домашние задания на несколько дней

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

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