Примечание от переводчика:

Этот пост был написан и опубликован на Medium разработчиком приложений Адрианом Космачевским из Швейцарии. Кроме подготовки перевода его публикации, я также пригласил и самого автора, Адриана ( akosma ), на Хабр, для того, чтобы он смог лично ответить на любые вопросы участников сообщества, если таковые возникнут. Думаю, для общего удобства при общении в комментариях с ним стоит использовать английский (и, при желании, дублировать на русском).

---

Привет всем, я — сорокадвухлетний программист-самоучка, а это моя история.

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



Эти размышления привели меня туда, откуда все начиналось.

Я дебютировал в роли разработчика программного обеспечения в 10 часов утра 6 октября 1997 года, в городе Оливос, к северу от Буэнос-Айреса, в Аргентине. Был понедельник. Не так давно я праздновал свой 24-й день рождения.

Мир в 1997 году

Тогда он был немного другим. На веб-сайтах не было предупреждений об использовании cookie. Новаторскими в сети были сайты вида Excite.com, а моим любимым поисковиком был AltaVista.

Мой электронный ящик имел вид kosmacze@sc2a.unige.ch и был расположен на личном веб-сайте, который размещался по адресу http://sc2a.unige.ch/~kosmacze. Тогда мы еще оплакивали принцессу Диану, а Стив Джобс только-только вернулся на роль CEO и убедил Microsoft «вбросить» в Apple Computer 150 миллионов долларов. Digital Equipment Corporation подала в суд на Dell, останки Че Гевары вернули на Кубу, только начался четвертый (!) сезон «Друзей». Был убит Джанни Версаче, скончались Мать Тереза, Рой Лихтенштейн и Жанна Кальман. Люди зависали за Final Fantasy 7 на PlayStation, будто бы были наркоманами, Би-Би-2 начал вещание телепузиков, а Кэмерон только собирался показать миру свой «Титаник».

Это третья часть эксперимента по созданию системы распознания мошеннических платежей (antifraud-система). Целью является создание доступного (в плане стоимости разработки и владения) antifraud-сервиса, который позволит сразу нескольким участникам проведения online-платежей – мерчантам, агрегаторам, платежным системам, банкам – снизить риски проведения мошеннических платежей (fraud) через их площадки.

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

Границы моего языка олицетворяют границы моего мира.
— Людвиг Витгенштейн

Последние несколько месяцев я пишу только ECMAScript 6 код, воспользовавшись трансформацией [1] в поддерживаемые в настоящее время версии JavaScript.

Если вы когда-нибудь сталкивались с задачей ресайза картинок в браузере, то вы наверное знаете, что это очень просто. В любом современном браузере есть такой элемент, как холст (<canvas>). На него можно нанести изображение нужных размеров. Пять строчек кода и картинка готова:

function resize(img, w, h) {
  var canvas = document.createElement('canvas');
  canvas.width = w;
  canvas.height = h;
  canvas.getContext('2d').drawImage(img, 0, 0, w, h);
  return canvas;
}

Из холста картинку можно сохранить в JPEG и, например, отправить на сервер. Можно было на этом закончить статью, но сперва давайте взглянем на результат. Если вы поставите рядом такой холст и обычный элемент <img>, в который загружена та же картинка (исходник, 4 Мб), то вы увидите разницу.

Каждый C#-разработчик знает, что C#-компилятор переводит исходный код программы в промежуточный язык под названием Intermediate Language (IL). А за превращение IL в последовательность машинных команд чаще всего отвечает Just-In-Time-компилятор (JIT). Да, на сегодняшний день есть NGen, Mono AOT, .NET Native, но JIT-компиляция всё ещё лидирует в мире .NET-приложений. А вот работает этот самый JIT, знают далеко не все. Если брать в расчёт только реализацию .NET от Microsoft, то стоит различать JIT-x86 и JIT-x64. А ещё за дверями стоит RyuJIT который уже совсем скоро займёт почётное место основного JIT-компилятора. А если вы любите старые версии .NET, то полезно знать, что в разных версиях CLR логика работы JIT отличалась. Исходники у нас теперь открыты, вы можете их посмотреть и осознать, насколько же это большая и сложная тема. Сегодня мы не будем пытаться охватить её, а лишь кратко посмотрим на несколько интересных особенностей отдельных версий JIT-компиляторов. Итак, сегодня в номере:

• Почему короткий метод может не быть заинлайнен и как этого избежать
• JIT-баги: опасные и беспощадные
• Кто и как разматывает циклы
• Чем отличается размотка маленьких и больших циклов

Привет, хабровчане! Меня зовут Михаил Завилейский, я — генеральный директор замечательной компании DataArt. Мы занимаемся IT-аутсорсингом вот уже много лет, и все эти годы делаем все возможное, чтобы по духу оставаться все той же группкой профессионалов, собравшейся зарабатывать любимым делом, с которой все когда-то и начиналось. И пусть сейчас нас уже больше тысячи, мы отчаянно стараемся не превратиться в «корпорацию».

Примерно 10 лет назад к нам на работу перешло несколько сотрудников из конкурирующей компании. Компании очень хорошей, на тот момент куда более зрелой и успешной, чем мы. На мой естественный вопрос о причинах было сказано, что компания-конкурент, оставаясь всё еще маленькой, «слишком быстро стала приобретать недостатки большой». Мысль прочно засела в голову, и уже десять лет мы стараемся расти, но недостатки приобретать как можно медленнее.

Откуда в компаниях берутся лишние рутины, бесполезные функции и менеджеры, бесцельные отчеты и ритуалы? В основном, это следствие трех причин:

1. Излишняя систематизация.
2. Инерция и шаблонность.
3. Управленческие ошибки.

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

Цели: классические. Повысить качество работы, эффективность, вывести отдел на новый уровень в целом.

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

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

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

Краткий спойлер содержимого: VCS, репозиторий исходного кода, code-review, build-сервера, CI, таск-трекер, вики, корпоративный блог, функциональное тестирование, репозиторий для пакетов, система управления конфигурацией, бэкапы, почта/jabber.

Картинка с фрагментом обсуждаемой инфраструктуры:

История — великое дело, особенно в такой быстро меняющейся области как IT!

Создатели http://1x-upon.com/ сделали реально работающие «древние копии» YouTube, Facebook и Google+ (даже с фреймами). Авторы рекомендуют вспомнить, что такое Netscape Navigator 4.03 и просматривать сайты с разрешением 1024×768, желательно на CRT-мониторе; желающие могут в виртуальной машине запустить Windows 95. Для полноты ощущений соединение с сервером ограничено 8 kB/s — как в настоящем dial-up.

YouTube

Facebook

Google+

но какие интерфейсы, а!

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

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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

Вы создали WebAPI и теперь хотите контролировать доступ к нему? В этой серии статей мы рассмотрим несколько вариантов защиты WebAPI от неавторизрованых пользователей. Серия будет охватывать обе стороны, и аутентификацию и авторизацию пользователей.

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

Первая серия статей дает общий обзор аутентификации и авторизации в ASP.NET Web API. Другие статьи описывают общие сценарии аутентификации для WebAPI.

Привет, хабралюди. Сегодня мы рассмотрим один из механизмов CLR, который напрямую недоступен для разработчиков на языке C# — фильтры исключений.

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

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

Под катом — код на VB.NET, F#, CIL и C#, а также проверка различных декомпиляторов на обработку механизма фильтров.

Часто мы делаем проекты продолжительностью в несколько месяцев. При этом горизонт планирования команд в Сибириксе — порядка пяти недель. В переложении на спринты — 3-5 спринтов (зависит от опыта конкретной команды).

Я использую два монитора, Google-календарь, Scrumban, общую тетрадь и песочные часы. Сам способ постоянно дорабатывается, но общие принципы остаются неизменными: держать под рукой все проекты в рукописном виде + управлять движением проектов на виртуальной канбан-доске.



Сама процедура занимает 2 часа в неделю. Этого времени достаточно, чтобы распланировать нагрузку примерно на 35-50 человек. Удобно делать либо рано утром в понедельник, либо в пятницу, во второй половине дня, либо в воскресенье вечером.

Всем доброго времени суток. Как-то так получилось, за последнее время я увидел много интересных и полезных инструментов/библиотек/событий, которыми я хотел поделиться на Хабре. Все эти темы по отдельности, на мой взгляд, не заслуживали целой статьи. Но каждая из них достойна внимания и может кому нибудь пригодиться. В итоге получился небольшой дайджест:

Prepros

Великолепное приложение препроцессор для CSS, JS. Компилирует файлы следующих типов: LESS, Sass, SCSS, Stylus, Jade, Slim, Coffeescript, LiveScript, Haml. Минифицирует JS на лету, при каждом изменении файла. Оптимизирует изображения. Доступен для Windows и Mac, а также как расширение для Chrome. Плюс ко всему создает HTTP сервер, для тестирования сайта на разный устройствах. Бесплатная замена CodeKit'у и Ghostlab'у вместе взятых, что в сумме позволит Вам сэкономить $75.

Введение

Во многих web проектах присутствуют элементы, значение которых необходимо часто менять. Это могут быть счётчики, индикаторы, уведомления и подобные элементы. Показывать ли актуальные значения после обновления страницы или же можно реализовать автообновление всех этих данных? Для нас ответ очевиден: если есть возможность динамически менять элементы, то для обновления страниц не остается места.

Введение

Приветствую вас, хабравчане. В данном топике я хотел бы осветить подробности разработки на C# под разнородные целевые платформы, в первую очередь такие как .NET и браузер (JavaScript). В качестве примера желающие могут изучить веб-сервис по обработке фотографий gfranq.com, в котором реализована клиентская и серверная обработка фотографий с помощью фильтров, а также функциональность коллажей на основе материала, описанного в данной статье.

Так как я не умею подбирать картинки для привлечения внимания, то она будет по теме:

Преамбула

Здравствуйте. Я являюсь главным разработчиком крупнейшего в СНГ сервера Minecraft (не буду рекламировать, кому надо, те знают). Уже почти год мы пишем свою реализацию сервера, рассчитанную на больше чем 40 человек (мы хотим видеть цифру в 500 хотя бы). Пока всё было удачно, но последнее время система начала упираться в то, что из-за не самой удачной реализации сети (1 поток на ввод, 1 на вывод + 1 на обработку), при 300 игроках онлайн работает более 980 потоков (+ системные), что в сочетании с производительностью дефолтного io Явы даёт огромное падение производительности, и уже при 100 игроках сервер в основном занимается тем, что пишет/читает в/из сети.

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

Здесь я постараюсь расписать серверную часть работы с сетью через Netty, может быть это кому-то будет полезно.

Введение

Обычно, при оптимизации программы для многоядерных компьютеров первым шагом является выяснение возможности разделения алгоритма на части, выполняющиеся параллельно. Если для решения задачи необходимо параллельно обрабатывать отдельные элементы из большого набора данных, то первыми кандидатами станут новые возможности параллельности в .NET Framework 4: Parallel.ForEach и Parallel LINQ (PLINQ)

Parallel.ForEach

Класс Parallel содержит метод ForEach, представляющий собой многопоточную версию обычного цикла foreach в C#. Подобно обычному foreach, Parallel.ForEach выполняет итерации над перечислимыми данными (enumerable), но с использованием множества потоков. Одна из более часто используемых перегрузок Parallel.ForEach выглядит следующим образом:

public static ParallelLoopResult ForEach<TSource>(
			 IEnumerable<TSource> source,
			 Action<TSource> body)

Ienumerable указывает на последовательность, по которой нужно выполнить итерации, а Action body задает делегат, вызываемый для каждого элемента. Полный список перегрузок Parallel.ForEach можно найти здесь.

PLINQ

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

Выполнение независимых операций