GopherCon 2019

Побывали на Российской ГоферКонфе 🙂

Было очень полезно и интересно, очень понравились доклады от Konrad Reiche(go generate: One File to Rule Them All) и Денис Исаев(Линтеры в Go: как их готовить).

http://gophercon-russia.ru

Golang Hints: Create MongoDB Object ID from String

Sometimes you may want to find something by the Object ID in your MongoDB and due to you URI or query string contains ID you should convert the string ID to Object ID.

Below is a code that converts string ID to Object ID:

 package main

import (
"go.mongodb.org/mongo-driver/bson/primitive"
"fmt"
)
func main() {
oid, err := primitive.ObjectIDFromHex(recordID)

fmt.Printf("%s %v", err, oid)

  // if err := collection.FindOne(ctx, bson.M{"_id": oid}).Decode(e); err != nil {
  // return nil, err
// }
}

Presenting Go-Up

Today I have started development of new package for Golang-developers – Go-Up. I made it because I have noticed that I should repeat some things with each new project on Golang, so the main purpose of Go-Up package is to simplify building of new Golang applications.

This is a beginning so I just want to share link to GitHub here – https://github.com/ildarusmanov/go-up

go build failed with “errors.go:121:2: undefined: stack”

Problem that I have met today:

$ go build
# github.com/pkg/errors
../../../../pkg/mod/github.com/pkg/errors@v0.8.0/errors.go:121:2: undefined: stack

#How to solve

I don't know the source of the problem, but I have fixed it with upgrading errors package version in my go.mod file:

module github.com/project_package
require (
// ...
github.com/pkg/errors v0.8.1 // indirect
// ...
)

Golang 1.11.2: dep ensure failed

Problem:


$ dep ensure
panic: version queue is empty, should not happen
goroutine 1 [running]:
github.com/golang/dep/gps.(*solver).findValidVersion(0xc00021e000, 0xc00026ac80, 0xc0001e6440, 0x1, 0x1, 0x0, 0xc0001e6440)
/home/travis/gopath/src/github.com/golang/dep/gps/solver.go:915 +0x4ec
github.com/golang/dep/gps.(*solver).createVersionQueue(0xc00021e000, 0xc0003ab0c1, 0x14, 0x0, 0x0, 0xc0001e6440, 0x1, 0x1, 0x0, 0x0, ...)
/home/travis/gopath/src/github.com/golang/dep/gps/solver.go:902 +0x46e
github.com/golang/dep/gps.(*solver).solve(0xc00021e000, 0xa64e60, 0xc0000a8188, 0x7c72ab, 0x936c80, 0xc00003c060)
/home/travis/gopath/src/github.com/golang/dep/gps/solver.go:505 +0x611
github.com/golang/dep/gps.(*solver).Solve(0xc00021e000, 0xa64e60, 0xc0000a8188, 0xdfa9c8, 0xc00002c0dc, 0x1f, 0xc00019b5c0)
/home/travis/gopath/src/github.com/golang/dep/gps/solver.go:440 +0xc0
main.(*ensureCommand).runUpdate(0xc000185960, 0xc0000c6980, 0xc00019a860, 0x0, 0x0, 0xc0000f6090, 0xa68f00, 0xc0000afc80, 0xc00002c0c4, 0x37, ...)
/home/travis/gopath/src/github.com/golang/dep/cmd/dep/ensure.go:356 +0x1c0
main.(*ensureCommand).Run(0xc000185960, 0xc0000c6980, 0xc00019a860, 0x0, 0x0, 0x0, 0x0)
/home/travis/gopath/src/github.com/golang/dep/cmd/dep/ensure.go:216 +0x7d4
main.(*Config).Run(0xc0000af0e0, 0x0)
/home/travis/gopath/src/github.com/golang/dep/cmd/dep/main.go:212 +0x1070
main.main()
/home/travis/gopath/src/github.com/golang/dep/cmd/dep/main.go:84 +0x53d
The command "dep ensure -update" failed and exited with 2 during .

Solution:

Add to your Gopkg.toml this lines:


[[override]]
name = "gopkg.in/fsnotify.v1"
source = "gopkg.in/fsnotify/fsnotify.v1"

And try to start dep ensure again.

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

Приятное сообщение от приятного HR приятной IT-компании 🙂

Если нужно быстро сделать стартап или реанимировать существующий для веб и мобилки, рекомендую – https://www.flatstack.com/

Golang и WOPI: превью документов через Office Online

Введение

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

Теория

По счастливому стечению обстоятельств для работы с документами в Office Online используется неплохо задокументированный протокол – WOPI (http://wopi.readthedocs.io/).

Что нам нужно реализовать для организации предпросмотра:

1) Нужно получить необходимые для обращения к Office Online данные:

– файл discovery.xml

– ссылка на файл /wopi/<fileId> и ссылка на действие офис онлайн из файла discovery.xml

– токен и время его жизни в виде таймстемпа в миллисекундах

2) Нужно написать реализацию метода CheckFileInfo, который будет возращать информацию о файле

3) Нужно написать реализацию метода GetFile, который будет возращать содержимое файла

Практика

Лучше слов расскажет код, шутка, на самом деле мне пока немного лень писать то, как это было реализовано 🙂

Но надеюсь, что и этот код сможет оказаться полезным.

https://github.com/ildarusmanov/msofficepreview

Зарегистрировал аккаунт на hackerrank.com

Зарегистрировался на сервисе hackerrank.com. Что это за сервис?

HackerRank — это социальная платформа, которая предлагает задания разной сложности по программированию. Запущена платформа была в 2012 году. Сейчас аудитория проекта насчитывает около полутора миллиона пользователей. Статистику по результатам решений заданий своими пользователями ресурс регулярно публикует в виде рейтинга по 50 странам. (источник: https://geektimes.ru/post/280074/)

Хочу отметить удобный интерфейс и интересные задачи, рекомендую для тех, кто хочет держать себе в форме 🙂

Ссылка на мой аккаунт: https://www.hackerrank.com/wajox

TDD заметки: как быстро начать разрабатывать через тестирование

Введение

Сегодня хочу рассказать о некоторых своих размышлениях по поводу TDD в этой небольшой заметке.

Первое, что такое TDD? Wiki говорит нам следующее(https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5):

Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование поощряет простой дизайн и внушает уверенность (англ. inspires confidence).

Кстати, рекомендую прочитать книгу о TDD самого Кента Бега(http://www.ozon.ru/context/detail/id/1501671/). О том для чего и когда использовать TDD я в этой заметке писать не буду, т.к. я думаю, что это достаточно очевидный момент и как правило вопрос возникает как к этому подходу разработки перейти и как его успешно внедрять.

Workflow

Ниже на рисунке представлен процесс разработки программы в стиле TDD.

tdd-flowchart
процесс разработки программы в стиле TDD

Начинается весь процесс всегда с написания тестов и далее двигаемся по стрелочке:

1. Написание теста, без написания логики программы, которую мы проверяем в тесте.

2. Запуск теста и проверка того, что тест красный, т.к. у нас нет реализации тестируемой части(если тесты зеленые – значит тесты ничего не проверяют и их нужно переписать)

3. Пишем код, который делает тесты зелеными(минимальный код, а точнее любой корректно  работающий код, который сделает тесты зелеными)

4. Запускаем тесты и проверяем, что они зеленые

5. Рефакторинг, мы переписываем наш "говнокод" для озеленения тестов, так, чтобы он был работающим и хорошо пахнущим не только для тестов, но и для нас.

Проблема первого теста

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

1. Написать сначала интерфейс, затем переходить к тесту. Это позволит начать переход к TDD и при этом не слишком "тупить" над тем, что и как тестировать, т.к. часть кода вы уже будете писать до теста и в голове уже будет небольшое понимание того, что тестировать. Ну а как привыкните – начнете писать тесты сразу.

2. Это писать сначала самый короткий, т.е. минимальный и общий тест. Собственно это и есть праведный путь TDD. Таким образом дизайн программы будет строиться по циклу через тесты, с каждой итерацией вы будете добавлять тесты и код.

Проблема плохого дизайна

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

1. Писать проект заново, особенно если в пользу этого уже есть какие-нибудь и другие предпосылки.

2. Выделять из проекта отдельные компоненты и тестировать их. Этот вариант подходит для проектов с не слишком НЕудачным дизайном.

3. Использовать TDD только для новых изменений кода и со временем весь проект сможет перейти на TDD. Этот вариант на мой взгляд самый универсальный.

Заключение

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

 

 

Как проверить навыки кандидата на собеседовании?

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

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

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

А вот далее желательно попросить написть немного кода для демонстрации, чтобы показать на самом ли деле он это умеет делать и еще можно попросить выполнить тестовое задание(если не боитесь, что кандидат отвалится).

+Отличным показателем являются аккаунт на github, активность в блогах, форумах и т.д.

О том как лучше спрашивать, мне понравилась вот эта статья – http://prohr2.ru/%D1%81%D0%BE%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE-%D0%B6%D0%B5%D0%BB%D0%B0%D0%B5%D0%BC%D1%8B%D0%B5-%D0%BE%D1%82%D0%B2%D0%B5%D1%82%D1%8B-%D0%B8-%D0%BA%D0%B0%D0%BA-%D1%81-%D0%BD%D0%B8%D0%BC%D0%B8/