Слоеная архитектура – это спасение в мире корпоративной разработки. С ее помощью можно разгрузить железо, распараллелить процессы и навести порядок в коде. Мы попробовали использовать паттерн CQRS при разработке корпоративного проекта. Всё стало логичнее и … сложнее. Недавно я рассказал о том, с чем пришлось столкнуться, на митапе Panda-Meetup C# .Net, и вот теперь делюсь с вами.

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

В первой части я сказал, что хеш таблица это немного LIST, SET и SORTED SET. Судите сами — LIST состоит из ziplist/linkedlist, SET состоит из dict/intset, а SORTED SET это ziplist/skiplist. Мы уже рассмотрели словарь (dict), а во второй части статьи будем рассматривать структуру ziplist — вторую наиболее часто применимую структуру под капотом Redis. Посмотрим на LIST — вторая часть его «кухни» это простая реализация связного списка. Это пригодится нам, чтобы внимательно рассмотреть часто упоминаемый совет об оптимизацию хеш таблиц через их замену на списки. Посчитаем сколько памяти требуется на накладные расходы при использовании этих структур, какую цену вы платите за экономию памяти. Подведём итоги при работе с хеш таблицами, при использовании кодировки в ziplist.

В прошлый раз мы закончили на том, что сохранённые с использованием ziplist 1,000,000 ключей заняли 16 мб оперативной памяти, тогда как в dict эти же данные потребовали 104 мб (ziplist в 6 раз меньше!). Давайте разбираться какой ценой:

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

Если вы знаете, почему после выполнения `hset mySey foo bar` мы потратим не менее 296 байт оперативной памяти, почему инженеры instagram не используют строковые ключи, зачем всегда стоит менять hash-max-ziplist-entries/hash-max-ziplist-val и почему тип данных, лежащий в основе hash это и часть list, sorted set, set — не читайте. Для остальных я попробую об этом рассказать. Понимание устройства и работы хеш таблиц в Redis критически важно при написания систем, где важна экономия памяти.

О чём эта статья — какие расходы несёт Redis на хранения самого ключа, что такое ziplist и dict, когда и для чего они используются, сколько занимают в памяти. Когда hash хранится в ziplist, когда в dicth и что нам это даёт. Какие советы из модных статей об оптимизации Redis не стоит воспринимать всерьёз и почему.

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

Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

Команда браузера Google Chrome проделывает огромную работу для того, чтобы разработчикам жилось лучше. Chrome DevTools — пример замечательного инструмента, сильно упрощающего отладку вашего веб-приложения. Но подчас не весь функционал этой системы виден с первого взгляда, поэтому Umar Hansa — программист из Лондона — описывает его на своем сайте, причем в весьма удобном формате: немного текста и короткий скринкаст. А мы, в свою очередь, решили сделать эти советы более доступными русскоязычной аудитории.

Содержание:

1. Перенаправление порта позволит вам открывать локальные ссылки на мобильном устройстве
2. Активация псевдо-классов DOM-элемента
3. Повтор сетевого запроса при помощи cURL
4. Запуск сохранённых блоков кода (сниппетов) на любой веб-странице
5. Отслеживание изменений файлов через DevTools
6. Простая запись действий страницы
7. Поиск элементов DOM-дерева при помощи CSS-селекторов
8. Копирование изображения в формате Data URI
9. Переход к нужной строке при открытии файла
10. Упрощенная навигация между правками
11. Копирование ответа на сетевой запрос
12. Работа с несколькими курсорами при редактировании скриптов
13. Блочное выделение
14. Быстрый мониторинг событий в консоли
15. Доступ к выбранному DOM-узлу в консоли
16. Отслеживание незавершенных сетевых запросов при помощи фильтра is:running

Продолжение: 17-32, 33-48.

Один технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой

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

Привет, Хабр!

Мы в Хекслете используем JavaScript не только для очевидных задач во фронтэнде, но и, например, для реализации браузерной среды разработки (наш опен-сорсный hexlet-ide) на React'е. У нас есть практический курс по JavaScript, и один из уроков там посвящен замыканиям. Это важная тема не столько в рамках JS, сколько в программировании вообще. Мы освещаем ее и в других курсах.

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

Я использую замыкания уже достаточно давно. Я научился их использовать, но не до конца понимал как они на самом деле работают, что происходит «под капотом». Что это вообще такое? Википедия не очень помогает. Когда замыкание создается и уничтожается? Как выглядит реализация?

"use strict";
 
var myClosure = (function outerFunction() {
 
  var hidden = 1;
 
  return {
    inc: function innerFunction() {
      return hidden++;
    }
  };
 
}());
 
myClosure.inc();  // возвращает 1
myClosure.inc();  // возвращает 2
myClosure.inc();  // возвращает 3
 
// Ага, круто. А как это реализовано?
// И что происходит под капотом?

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

Когда .NET разработчик слышит слова «В проект нужно добавить workflow», то первым приходит в голову идея взять Windows Workflow Foundation.

В 2010 году мы выбрали WF в качестве движка документооборота.

Аргументы просты:

• Бесплатно;
• Встроено в Visual Studio;
• В интернете много информации об использовании WF.

За полтора года (с августа 2010 по февраль 2012) использования WF мы столкнулись с массой разнообразных проблем при реализации требований клиента. В конечном итоге мы были вынуждены отказаться от Windows Workflow Foundation и сделать свою реализацию State Machine.

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

Мы с вами люди рабочие и зачастую не замечаем ничего что происходит за пределами нашей работы. Так и я, работая изо дня в день, знаю только про свой SpecFlow и смежные вопросы. Но ничего – по сторонам. Этим постом я хочу восполнить пробелы новостей в области .Net

Новости хаба .Net на Хабре занимают 33 страницы или 328 постов. Что говорит о том что новости появляются почти каждый день =) Посмотрим на самое интересное из них (на мой скромный взгляд). Ну и загляните под кат: до ката, конечно же, не все.

Доступен новый JIT: теперь с поддержкой SIMD
Как работает декомпиляция в .Net или Java на примере .Net
Microsoft раскрыла исходный код компилятора С#
Consulo: ~1000 коммитов, или как прошла осень
Под капотом у Stopwatch
Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

Привет, Хабр!

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

Тема SPA-приложений и javascript-приложений в целом не нова, но нам не удалось найти даже на платных ресурсах основательных руководств по разработке приложений. Они являются скорее рассказом о той или иной MV*-библиотеке, чем примером для подражания. При этом не рассматриваются примеры разбиения по слоям, построения иерархий наследования и тонкостей наследования в javascript и т.д.

Мы попробуем зайти с другой стороны и описать, скорее, ход мыслей при разработке (с кодом и ссылками), чем какой-то конкретный инструмент. Начать мы вынуждены с уровня hello world, чтобы задать одну стартовую точку для читателей и писателя. Но уже со второго раздела повествование резко ускорится.

Мы считаем, что данная статья будет полезна:

1. Front-end разработчикам, у которых уже есть небольшой опыт, но хочется вырасти.
2. Back-end разработчикам, которым в какой-то момент пришлось начать заниматься js-разработкой и которые чувствуют некую неуверенность при работе с javascript.
3. Верстальщикам, которые начали заниматься js-разработкой и хотели бы прокачать свои навыки.

Чтиво получилось весьма объемистым, но надеемся, что настолько же полезным.

Добрый день, читатели Хабра!

Сразу скажу, что целевая аудитория поста и события: руководители в разработке на C#/.Net, в том числе тимлидеры и менеджеры проектов. И те, кто планирует переходить на руководящую позицию.

Я поделюсь логикой формирования программы второго дня конференции Go#.
Мы взяли темы, которыми должен владеть человек на руководящей позиции в разработке. При этом конкретная имплементация этих знаний должна быть специфична для экосистемы C#/.Net.

Для мероприятия с одним треком программа получилась концентрированной. Расписание включает 10 докладов по 15-30 минут, обед в кафе и кофе брейки – и все это с 10.00 до 17.00.

Темы: от архитектуры .Net приложений до механики решений по формированию команд и распределению задач. И, конечно же, управление проектом и исходным кодом. Докладчики представят две полярные парадигмы – классическую Application Lifecycle Management на базе TFS и альтернативные подходы с применением Git и DevOps инструментов.

Наши спикеры начинали как C#/.Net разработчики, но многие имеют опыт руководства коллективами и проектами с десятками и даже сотнями разработчиков.

Сайт тимлидерского дня конференции Go# – www.gosharp.ru/TLD2014

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

Наиболее существенные из них:

• невозможность повторного использования кода page-объектов для страниц с одинаковыми элементами;
• плохая читаемость и отсутствие наглядности кода для страниц с большим количеством элементов;
• отсутствие типизации элементов.

Из этого поста вы узнаете, как мы в Яндексе решаем эти проблемы с помощью фреймворка с открытым исходным кодом HTML Elements. Он расширяет концепцию шаблона Page Object и позволяет сделать взаимодействие с элементами на веб-страницах простым, гибким и удобным.

Мы не будем останавливаться на описании самого паттерна и его принципов, поскольку большинству из вас он наверняка хорошо знаком. Если же кто-то с ним не встречался, то узнать о нём можно из этого поста или мастер-класса. Также, говоря о применении паттерна Page Object, мы будем подразумевать его Java-реализацию в фреймворке Selenium WebDriver.

Повторное использование кода

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

Сегодня JavaScript лежит в основе большинства современных веб-приложений. При этом за последние годы появилось большое количество JavaScript-библиотек и фреймворков для разработчиков Single Page Application (SPA), графики, анимации и даже серверных платформ. Для веб-разработки JavaScript используется повсеместно, и поэтому качество кода обретает всё большее значение.

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

Вообще-то, в фильме была в основном ложь обо мне. Я был инженером в HP, разрабатывающим iPhone 5 того времени, их инженерные калькуляторы. Там у меня было много друзей и хорошая репутация. Я создавал вещи для людей по всей стране для развлечения, включая первую систему проката фильмов для отелей и считыватели таймкодов SMPTE для мира коммерческого видео. Ещё домашние пинболл-игры.

Среди этих вещей, Apple I был ПЯТЫМ случаем, когда что-то, что я создал (а не собрал на основе чьей-то схемы), было превращено в деньги Джобсом.

Совместная фотография, 1981 год

Сегодня Пол Аллен (думаю, вряд ли его персона нуждается в представлении) выложил свою фотографию вместе с Биллом Гейтсом. Это фото намеренно сделано похожим на аналогичное фото из 1981 года. ПК и люди на этих фотографиях одинаковы. Вот только возраст, конечно же, отличается.

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