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



В общем, если вам интересен рассказ о том, как C++ программист из Подмосковья искал работу в Европе, желательно в Великобритании, а нашел-таки в Нидерландах, переехал туда сам и привез жену, все это с непогашенной ипотекой в России и с небольшими приключениями — добро пожаловать под кат.

Одностраничные приложения (SPA) имеют мнжество преимуществ, таких как скорость, по-настоящему хороший UX, и полный контроль HTML-разметки. Становится всё больше и больше сайтов SPA; всё больше инструментов, которые упрощают процесс разработки SPA. Вы, вероятно уже читали о молодом и перспективном фреймворке Vue.js. Предлагаю вам глубже погрузиться в Vue и на конкретном примере разобраться с простым SPA.

Мы напишем клиент-серверное приложение простейшего блога. Приложение будет отображать список записей а также полный текст каждой отдельной записи. И само собой, всё это будет происходить без перезагрузки страницы.

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

Научитесь выявлять их. Выработайте привычки избегать их.

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

От переводчика

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

Как бы это смешно не звучало, я работал над этим текстом с середины марта, стараясь подобрать подходящие формулировки и упростить для восприятия. Ещё пару дней воевал с хабра-редактором. Поэтому, если вы найдёте недочёты, прошу не винить меня в нерадении, а оповестить, я их сразу же исправлю. Я думал украсить статью картинками, но решил, что это только раздует её до совсем неприличных размеров. Приятного чтения.

Коротко: небольшой самодостаточный пример, иллюстрирующий SignalR для .NET Core 2 и разработку в IDE Rider. В самом конце — видео Dino Esposito с конференции DotNext на эту же тему.

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

Очевидно, есть готовые библиотеки, которые берут это на себя. В мире веб-приложений ASP.NET это SignalR, она позволяет разработчику абстрагироваться от перечисленных сложностей и использовать простую программную модель для работы с push-уведомлениями.

Приветствую всех. Сегодня расскажу вам как я проходил собеседования в Москве на позицию .Net Developer. Усиленно готовился к собеседованиям месяц, целыми днями сидел и смотрел вопросы и пытался отвечать на них, а также читал книжки по С#. В статье привожу интересные задачки и вопросы, которые мне задавали в разных компаниях в Москве. Заранее скажу, что я попал в ту компанию, в которую хотел. Я прошел 4 собеседования в этой компании и меня наконец то взяли! Много статей было прочитано в частности здесь и надеюсь, что эту статью тоже будут читать начинающие Net разработчики и спрашивать все в комментариях.

Кому интересна тема прохождения собеседований, прошу под кат!

Kismet — это многофункциональная бесплатная утилита для работы с беспроводными сетями Wi-Fi. Пользователям она знакома в основном по статьям на тему взлома, где программа используется для обнаружения скрытых сетей или захвата пакетов. Взламывать чужие сети — плохо, а между тем Kismet — это гораздо больше чем отмычка в руках злоумышленника. В арсенале инженера информационной безопасности эта программа становится прекрасным инструментом для наблюдения и анализа эфира 802.11.

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Автор: Вячеслав Михайлов, Solutions Architect.

В этой статье я поделюсь опытом проектирования RESTful API — на конкретных примерах покажу, как делать хотя бы простые сервисы красиво. Также мы поговорим, что такое API и зачем он нужен, поговорим об основах REST — обсудим, на чем его можно реализовывать; коснемся основных веб-практик, которые зависят и не зависят от этой технологии. Также узнаем, как составлять хорошую документацию, затрачивая на это минимум усилий, и посмотрим, какие существуют способы нумерации версий для RESTful API.

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  
  • XML-RPC and JSON-RPC
  • SOAP
  • REST
  
  
• WebSockets APIs
• Library-based APIs
  
  • Java Script
  
  
• Class-based APIs
  
  • C# API
  • Java
  
  

Виды API по категориям применения:

• OS function and routines
  
  • Access to file system
  • Access to user interface
  
  
• Object remoting APIs
  
  • CORBA
  • .Net remoting
  
  
• Hardware APIs
  
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …
  
  

Хочу представить вашему вниманию комические купле каверзные вопросы по C#.
Не удержался и решил запостить немного классики.
Некоторые вопросы в подборке кому-то могут показаться слишком простыми, но небольшой подвох в них, как правило, есть. Иногда можно и простым вопросом подловить. Будут полезны тем, кто изучает язык.
Всех, кому интересно, прошу под кат!

Если вы знаете, почему простая строка `strings` в Redis займёт в оперативной памяти 56 байт — вам, думаю, статья не будет интересна. Всем остальным я попробую рассказать, что такое строки в Redis и почему использующему эту базу данных разработчику важно понимать, как они устроены и работают. Это знание особенно важно, если вы пытаетесь рассчитать фактическое потребление памяти вашим приложением или планируете строить высоко нагруженные системы статистики или учёта данных. Или, как часто бывает, пытаетесь срочно понять, почему вдруг ваш экземпляр redis стал потреблять неожиданно много памяти.

При работе с Entity Framework, как и с любым другими ORM, часто возникают вопросы, связанные с его производительностью. Многие разработчики из-за незнания нюансов делают ошибки, приводящие к плохим результатам. Затем, во время анализа проблем и поиска решений, недостаточно разобравшись в вопросе, приходят к выводу, что улучшить ситуацию можно только переходом на другой ORM или отказом от него вообще. Хоть в некоторых ситуациях такое решение может оказаться разумным, зачастую не все так плохо — просто нужно знать нюансы. В этой статье я попытался собрать те подводные камни, с которыми мне чаще всего приходилось сталкиваться на практике.

Цель урока. Научиться работать с форматом json. Инструменты по работе с json. Написание сторонних запросов, авторизация через получение данных от facebook и vkontakte. Ajax в работе с json (авторизацию переписать). API сайта.

Json и Json.net

Json – это текстовый формат данных, основанный на Javascript.
Пример данных в Json:

{
            "firstName": "Иван",
            "lastName": "Иванов",
            "address": {
                "streetAddress": "Московское ш., 101, кв.101",
                "city": "Ленинград",
                "postalCode": 101101
            },
   "phoneNumbers": [
       "812 123-1234",
       "916 123-4567"
   	]
  }

В последнее время в научных публикациях всё чаще упоминается алгоритм достижения консенсуса в распределенных системах под названием Paxos. Среди таких публикаций ряд работ сотрудников Google (Chubby, Megastore, Spanner) ранее уже частично освещенных на хабре, архитектуры систем WANdisco, Ceph и пр. В то же время, сам алгоритм Paxos считается сложным для понимания, хоть и основывается он на элементарных принципах.

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

Интерес к рознице был заметен изначально — с самых первых статей на хабре и на других сайтах мы начали получать запросы на франшизу. Запросы шли со всей страны — Питер, Новосибирск, Краснодар, Ростов-на-Дону, Пермь, Хабаровск, Сочи и так далее. Даже страной дело не ограничилось — люди из Украины, Беларуси и Казахстана тоже хотели открыть у себя магазин Madrobots. Но франшиза — это в первую очередь отлаженные процессы. Как мы могли объяснять, как открыть магазины в других городах, если сами этого толком не умели?

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

Результаты отзывов

Про аудиторию

Так ка много комментариев было по этому поводу, то решил сделать последнюю попытку. Надеюсь на фидбек в комментариях — получилось «Для Всех» или нет.

Про книги

После прочтения комментариев решил опубликовать список книг, которые там рекомендовались:
C# 2008. Ускоренный курс
CLR via C#
C# и платформа .NET
C# 2.0. Полное руководство

Про разное

Были вопросы по поводу скорости Mono. на днях нашёл ссылку, на который есть небольшой тест. geekswithblogs.net
Тестирование проводилось на более ранних версиях, но я думаю ситуация не глобально изменилась. ИМХО

Ну а теперь давайте продолжим обучение…

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

Введение

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

Для любого программного приложения, предназначенного для массового обслуживания пользователей, необходимо проводить нагрузочное тестирование на предмет его надежности и отказоустойчивости. А так как любой web-сайт — это по своей сути система массового обслуживания, то проверка его на отказоустойчивость всегда является неотъемлемой частью разработки. Существуют различные решения для проведения нагрузочного тестирования веб-приложений. Я не буду сейчас описывать их подробно, про некоторые из них есть упоминания здесь.

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

Для тех кто ни разу не использовал JMeter, рекомендую для начала почитать базовые обзоры, например, Простой нагрузочный тест с Apache JMeter. Когда я первый раз запустил данную программу, первая мысль была разобраться во всем методом «тыка», но как выяснилось это вообще нереально, и метод «тыка» неприменим к JMeter. Поэтому если хотите его использовать, то сразу открывайте мануал, поверьте, вам придется заглядывать туда очень часто, пока полностью не разберетесь, что и как. Я же здесь сейчас опишу самое очевидное и важное, а именно: как собственно создавать нагрузочные тесты. Если бы я в свое время сразу нашел подобную статью, то сэкономил бы без малого день на изучении этой софтины.

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

1. Java Core
2. Junior Java Developer: Servlet API, JDBC, Maven, JUnit, Mockito, Log4J, основы Spring/SpringMVC, основы JPA/Hibernate, шаблоны/архитектуры MVC/IoC/DAO.
3. Multicore programming in Java.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

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

(GolovachCourses.com)

Здесь собраны несколько вариантов записи моего курса Java Core.
Модуль #1 (Procedural Java):
Набор июль 2013: #1, #2, #3, #4
Набор апрель 2013: #1, #2, #3, #4
Набор февраль 2013: #1, #2, #3, #4
Набор январь 2013: #1, #2, #3, #4
Набор октябрь 2012: #1, #2, #3, #4.

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

«Основная проблема интерфейса в том что это интерфейс. Интерфейсы — это препятствия на пути. Я не хочу сосредоточивать свои силы на интерфейсе. Я хочу сосредоточиться на работе… Я не хочу осознавать себя использующим компьютер, я хочу осознавать себя делающим дело».

Дональд Норман

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

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

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