Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

• разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
• UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.

Как это начиналось

Я всю жизнь занимался разработкой под Windows. Сначала на С++, затем на C#. В промежутках мелькали VB, Java Script и другая нечисть. Однако некоторое время назад всё изменилось и я впервые столкнулся с миром Linux, Java и Scala. У нас с Денисом, моим другом и соратником по многочисленным идеям, уже был свой проект – набор утилит для Windows, который пользовался широким спросом в узких кругах. В какой-то момент мы оба потеряли интерес к этому проекту и встал вопрос – что же делать дальше. Денис стал инициатором идеи нового проекта – сервис по обмену clipboard между разными устройствами. Этот проект существенно отличался от предыдущего помимо технологий ещё и целевой аудиторией. Этот сервис должен был стать полезен всем. Скопируйте данные в буфер обмена и вставьте из него на любом другом устройстве. Звучит проще некуда, пока не задумаешься над тем сколько сейчас разных устройств, а также как это все будет работать при большом количестве пользователей.
Первый прототип появился через несколько месяцев. Сервер был написан на ASP.NET и хостился на MS IIS. Было написано 2 клиента: на С++ под Windows и на Java под Android.



Тестирование показало, что прототип держит около 500 соединений. Что же делать, если их будет больше, мы ведь расчитываем на сотни тысяч пользователей ;) Как написать сервер, который может работать с большим количеством соединений, который не надо будет выключать во время апгрейда железа или софта и который будет легко масштабироваться (то есть расширяться в случае увелечения количества пользователей).

Мне часто приходилось сталкиваться с тем, что люди прекрасно понимают, что такое транзакции в базе данных и для чего они нужны, но при этом не всегда умеют ими правильно пользоваться. Безусловно, для достижения 80-го уровня сакрального знания нужно иметь не один год опыта и прочесть множество толстенных книг по SQL. Поэтому в этой статье я даже не буду пытаться описать всё, что может быть связано с транзакциями в MS SQL. Я хочу затронуть один простой, но очень важный вопрос, который разработчики часто упускают из вида – уровни изоляции транзакций.
Несмотря на то, что тема очень проста, во многих источниках она освящается плохо – информации либо очень мало, либо очень много. Т.е. прочитав 5-6 кратких теоретических определений невозможно их применить на практике. Для уверенного понимания предмета статьи нужно обращаться к специализированной литературе, но там информации на столько много, что далеко не каждый может уделить необходимое время для её усваивания.
Сегодня я хочу поделиться своим простым рецептом, который помог мне раз и на всегда запомнить особенности уровней изоляции транзакций и по сей день помогает без проблем принимать взвешенные решения о выборе необходимого уровня.

В предыдущей части были рассмотрены основы уровней изоляции транзакций. Здесь я постараюсь копнуть чуть глубже и рассказать при помощи каких инструментов MS SQL Server реализует уровни изоляции.

Как вы могли видеть в предыдущем разделе, существует два способа поддержания изоляции:

• Основанный на блокировке ресурсов
• Основанный на создании версионной копии ресурсов.

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

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

Статья 1. Почему я не преподаю SOLID

Если вы разговариваете с кем-то, кому небезразлично качество кода, уже достаточно скоро в разговоре всплывёт SOLID — аббревиатура, помогающая разработчикам запомнить пять важных принципов объектно-ориентированного программирования:

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

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

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

Разработка мобильных приложений — это всегда компромисс между тем, что хочется сделать и тем, что позволяет сделать платформа устройства. В этой статье рассказывается о том, как увеличить возможности приложения Android с помощью Golang.

Я — программист. А ещё я слеп. Слеп, как крот, как говорится. Таков я от рождения.

Когда я говорю об этом своим товарищам, то те из них, у кого никогда не было проблем со зрением, обычно задают один из трёх вопросов:

• Как же ты тогда можешь читать то, что я пишу?
• Ого. А как ты тогда можешь кодить?
• Или — самый популярный вопрос — А ты видишь сны?

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

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

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

Первая часть здесь. Продолжение:

Семь долбаных лет я ждал язык, который хоть как то ответит части моих желаний. За это время, и в фоновом режиме я препробывал всё. Всё — означает, всю херню общего назначения, и всю херню не совсем общего назначения. Нельзя прочувствовать язык только что-то прочитав про него и написав Hello World. Чтобы понять — надо хоть немного попрограммировать — написать какую нить вещь. И вот все это время, я в минуты отчаянья качал какой-нить “замечательный язык”, и пытался что-то написать. Какие-то вещи даже до сих пор крутятся в конторе (или крутились).

Так случилось, что у меня дома интернет на этом роутере QTECH 1040WU. Есть второй точно такой же. И есть дальняя комната в которой на смартфоне ловит сигнал очень слабо. Пришла в голову идея соединить их между собой, чтобы сигнал стал по-сильнее. Готовой инструкции для этих роутеров нигде не нашел. После изучения настроек аналогичных роутеров нужный результат был в итоге достигнут и решил поделиться настройками.