Создание веб-приложения на Go в 2017 году. Часть 4

Когда я смотрел go, первым плевком в мою душу было отсутствие «while»

Вот же он

for sum < 1000 {
	sum += sum
}

Сервисы на Go: как мы их пишем и поддерживаем

На схеме php выглядит как узкое горлышко в бутылке. Так ли оно на самом деле не берусь судить конечно.

UX-рецепт подтверждения номера телефона и электронной почты

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

И далее по тексту:

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

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

переадресация пользователя из письма идет на определенную страницу. И эта страница не профиль. Что жутко раздражает, не так ли?

Что мешает направить его на профиль с сообщением, что почта подтверждена?

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

Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам

На практике же — 90% из тех, кто помнит метод пузырька, его и будут использовать при необходимости написать сортировку. Прикола ради задали вопрос по пузырьку студенту стажеру. Нарисовал правильно. А он, на минуточку, человек, который пишет код уровня:

if (x === true) {
    toggle(true);
} else if (x === false) {
    toggle(false);
}

Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам

Ну а какая практическая польза в такой задаче на собеседовании?

Пиши на C как джентльмен

Вендоринг в go позволяет заморозить библиотеку на нужном коммите (если только там не разветвленная цепь зависимостей, которые вытянуть проблематично. Еще есть мой любимый gopkg.in (от создателей mgo), позволяющий использовать даже несколько версий одного пакета в одном приложении. Но тут проблема доверия и оф.поддержки для многих может стать решающим фактором.

Что я изменил бы в Go

А что является ограничителем сферы применения того же go?

Что я изменил бы в Go

Дело привычки. Не сложнее чем с разбиением, на мой взгляд.

Что я изменил бы в Go

Я имел в виду, что нормальной практикой является держать .go файлы в одном каталоге, особенно в небольших проектах. В моем случае это сервисы под linux-сервера и именование user.go и User.go вполне устраивает. Но, конечно же, это могут быть user.go и user-model.go и т.д. Ничего не имею против разделения по каталогам, все зависит от проекта и поставленных задач.

Что я изменил бы в Go

Я в таком случае создаю пакет controllers, где каждый элемент описывается в отдельном одноименном файле и представляет собой объект с необходимыми методами и свойствами.
Либо же вообще все ложу в корень проекта, применяя различные способы написания для файлов. Например users.go, Users.go. Это вполне нормальная практика для go, но по началу коробит многих, кто пришел с других языков, например с той же ноды.
В общем единого верного решения наверное не существует.

Что я изменил бы в Go

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

Как рендерится кадр League of Legends

Довольно странно выглядит гифка, где расходятся круги от статичных камушков, но не от чувака, болтыхающегося в ручье. Сколько лет этой игре?

Правила хорошего вкуса от Линуса Торвальдса. Делаем код быстрее, проще и понятнее

Стоило только поставить перед выражением if, как стало нечитаемо, вы правы.

Прохождение квеста от mail.ru

Или base64_decode('bm8gcGFpbiBubyBnYWlu') в консоль скопировать, оно же выполняется в итоге

Первоапрельский розыгрыш Gmail привел к потере работы некоторыми пользователями сервиса

Зачем писать за "всех"? Даже опрос под статьей выше показывает обратное.

За и против: Когда стоит и не стоит использовать MongoDB

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

За и против: Когда стоит и не стоит использовать MongoDB

1)

db.posts.aggregate([
    {$lookup: {"from": "comments", "localField": "_id", "foreignField": "postID", "as": "comments"}},  {$unwind : "$comments"},
    {$lookup: {"from": "users", "localField": "comments.userID", "foreignField": "_id", "as": "comments.user"}}, 
    {$group : { _id: "$_id", comments: {$push: "$comments"}}}
]);

2)

db.comments.aggregate([
    {$group: {_id: "$postID", count: { $sum: 1}}},
    {$lookup: {"from": "posts", "localField": "_id", "foreignField": "_id", "as": "post"}},  
]);

За и против: Когда стоит и не стоит использовать MongoDB

А вот-так даже красивее гораздо:

db.posts.aggregate([{$unwind : "$comments"}, {$match: {"comments.userID": 10}}]);

За и против: Когда стоит и не стоит использовать MongoDB

Сначала неверно истолковал вопрос, в таком случае требуется агрегация с группировкой:

db.posts.aggregate([{
    $project: {
        items: {
            $filter: {
                input: "$comments",
                as: "comm",
                cond: {
                    $eq: ["$$comm.userID", 10]
                }
            }
        }
    }
}, {
    $group: {
        _id: "all",
        messages: {
            "$push": "$items"
        }
    }
}]);

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

За и против: Когда стоит и не стоит использовать MongoDB

Если я хочу посмотреть все комментарии одного пользователя

db.comments.find({userID: 100500}).sort({date: -1})