По нашей просьбе Хабр создал хаб Kubernetes и нам приятно разместить первую публикацию в нём. Подписывайтесь!

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

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

В этом уроке мы будем изучать React Native – фреймворк от компании Facebook для создания нативных приложений под iOS и Android. У него много общего с другим очень популярным фреймворком от Facebook – React Javascript, который предназначен для построения декларативных пользовательских интерфейсов.

Благодаря популярности CSS фреймворка Bootstrap, для него разработали массу различных дополнений. Даже сейчас вы можете использовать Bootstrap практически для любой задачи при разработке и оформлении вебсайта.

Для статьи я подобрал наиболее полезные дополнения «на все случаи жизни».

Делюсь списком полезных источников по Angular 2. Подойдут как для начинающих, так и для тех, кто имеет опыт работы с фреймворком.

Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов.
Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

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

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

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

От переводчика. Судя по своему опыту, а также по опыту знакомых коллег-программистов, могу сказать, что для начинающего разработчика среди всех базовых функций языка C# и платформы .NET делегаты и события являются одними из наиболее сложных. Возможно, это из-за того, что необходимость делегатов и событий на первый взгляд кажется неочевидной, или же из-за некоторой путаницы в терминах. Поэтому я решил перевести статью Джона Скита, рассказывающую о делегатах и событиях на самом базовом уровне, «на пальцах». Она идеальна для тех, кто знаком с C#/.NET, однако испытывает затруднение в понимании делегатов и событий.

Представленный здесь перевод является вольным. Однако если под «вольным», как правило, понимают сокращённый перевод, с упущениями, упрощениями и пересказами, то здесь всё наоборот. Данный перевод является немного расширенной, уточнённой и обновлённой версией оригинала. Я выражаю огромную благодарность Сергею Теплякову aka SergeyT, который внёс неоценимый вклад в перевод и оформление данной статьи.

Люди часто испытывают затруднения в понимании различий между событиями и делегатами. И C# ещё больше запутывает ситуацию, так как позволяет объявлять field-like события, которые автоматически преобразуются в переменную делегата с таким же самым именем. Эта статья призвана прояснить данный вопрос. Ещё одним моментом является путаница с термином «делегат», который имеет несколько значений. Иногда его используют для обозначения типа делегата (delegate type), а иногда — для обозначения экземпляра делегата (delegate instance). Чтобы избежать путаницы, я буду явно использовать эти термины — тип делегата и экземпляр делегата, а когда буду использовать слово «делегат» — значит, я говорю о них в самом широком смысле.

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

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

Среди серьезных компании, пожалуй, можно выделить облачные решения от Amazon (SQS) и Microsoft (Service Bus). Однако, несмотря на бурное развитие Public Cloud, такие решения не всегда применимы, что называется On-Premises. Иными словами, есть потребность в таких решениях, но на собственных закрытых площадках. В связи с этим, Microsoft сделали грамотный шаг, сделав доступным Service Bus в Private Cloud, или как минимум на одной машине с установленной Windows 7 и выше. В версии Service Bus 1.0 было доступно управление через PowerShell, а с релизом 1.1 появилась возможность интеграции в консоль Azure Pack.

В этой статье я постараюсь описать процесс настройки Service Bus for Windows Server максимально подробно, в картинках. Так как лучше один раз увидеть процесс полностью, чем несколько раз прочитать по частям в разных источниках.

Осторожно трафик! Под катом много картинок.

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

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

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

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

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

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

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

Вы наверное что-то уже знаете о нашей компании?

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

Пишу отчет на основе последних 5 месяцев активного развития проекта.

Отчет состоит из 3 частей:
1. Какие IT специалисты сейчас нужны (на примере Германии). Думаю, что это касается и всей Европы, но пока что все устраиваются в Германии.
2. Какие важные моменты я заметил в процессе работы с кандидатами
3. Анонс по функционалу проекта (полезно будет и тем, кто пока что не собирается за границу)

1. Тренды.
Какие специалисты нужны чаще всего
Проект постоянно получает запросы на программистов уровня Senior и Team Lead.
Самые спрашиваемые языки программирования: PHP, JavaScript, NodeJs, Ruby, Scala и Java.
Frameworks не играют очень важной роли, но указывать их все же стоит. Например: Angular, React, Backbone, Zend
Также бывают запросы на UI-UX дизайнеров и QA. Но их заметно меньше.

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

Вид на City, сердце деловой Великобритании

Перед тем как перейти «на контракт» я работал в постоянным сотрудником в Лондоне в небольшой (700 серверов / 8 коллег) компании. Моя специализация — Wintel engineer, то есть я могу работать к в суппорте так и в техподдержке проектов. Все что связано с продуктами Microsoft. Я подумывал об уходе с постоянной работы, однако волею судеб пришлось уйти совершенно неподготовленным. Именно отсюда начинается мой рассказ о контрактниках в Великобритании.

Дисклеймер

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

Мы переехали в Лондон (Великобритания) из Хабаровска (Россия) в конце 2014. Мой муж senior php developer, с серьезным опытом работы c linux и вообще большой умница. Мой профессиональный багаж включает всякую ерунду типа FoxPro, но на последнем месте работы я занималась разработкой под интеграционную шину и JavaEE.

Шаг 1. Виза

Очевидно, чтобы приехать в Великобританию требуется виза, в контексте работы, пожалуй, наиболее реальный вариант Tier2 General.

Disclaimer

Текст не претендует на истину в последней инстанции, описанное ниже основано на собственном опыте и рекомендациях людей с больше чем двадцати годами опыта в IT в США и Канаде.

Анализ резюме рекрутером

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

У вас есть 3-5 минут чтобы заинтересовать своим резюме. Это то, сколько будет уделено времени на него в начале, в лучшем случае. Часто резюме могут отсеяться спустя 10 секунд. Вас никто не знает, вы это лист бумаги с текстом, и это единственное, что вас может отличить от других. Представьте, что вы хотите купить новый телевизор, вас вряд ли будут интересовать длинные мануалы или 5 страничные описания. Выбирая из десятков и сотен аналогов, нужно за 5-10 секунд сделать предварительный отсев по определенным параметрам. Оставшимся 5-10 устройствам вы выделите чуть больше времени, а потом еще помешкаете выбираю между двух. Как то так и происходит отбор кандидатов.

Moq – это простой и легковесный изоляционный фреймврк (Isolation Framework), который построен на основе анонимных методов и деревьев выражений. Для создания моков он использует кодогенерацию, поэтому позволяет «мокать» интерфейсы, виртуальные методы (и даже защищенные методы) и не позволяет «мокать» невиртуальные и статические методы.

ПРИМЕЧАНИЕ
На рынке существует лишь два фрейморка, позволяющих «мокать» все, что угодно. Это TypeMockIsolator и Microsoft Fakes, доступные в Visual Studio 2012 (ранее известные под названием Microsoft Moles). Эти фреймворки, в отличие от Moq, используют не кодогенерацию, а CLR Profiling API, что позволяет вклиниться практически в любой метод и создать моки/стабы даже для статических, невиртуальных или закрытых методов.