Пользователь
В прошлом уроке мы разобрались с тем, что такое OpenGL. В этом уроке мы поговорим о причине необходимости использования GLFW, GLEW и CMake, а также рассмотрим как их использовать. А также освежим в памяти, разницу между статической и динамической линковкой.
Второй причиной заблуждений могут служить, как это ни парадоксально, бенчмарки. К примеру, далее в этой статье мы будем измерять производительность блокировок под высокой нагрузкой: каждый поток будет требовать блокировку для выполнения любого действия, а сами блокировки будут очень короткими (и, в результате, очень частыми). Это нормально для эксперимента, но такой способ написания кода — это не то, что вам нужно в реальном приложении.
Начинающий программист Ewa Mitulska-Wójcik описала в недавней публикации на Медиуме свои мысли о необходимых разработчикам личных качествах. Публикуем перевод этой заметки и небольшой комментарий в самом конце.
Многим из нас проще выучить новый язык программирования, вместо того, чтобы поработать над мировоззрением и характером. Давайте посмотрим, почему некоторые разработчики далеко продвигаются в компаниях, а некоторые остаются затерянными в офисных кабинках.
Эффективное общение может сильно отличать среднего разработчика от высокопродуктивной "рок-звезды". Программирование — это общение не только с серверами, клиентами и кофемашинами, подключенными к сети. Быть в хороших отношениях с партнёрами по команде — важно.
Вот некоторые повседневные коммуникативные задачи, с которыми вам придётся столкнуться, как разработчику.
Оригинал: Bruno Marnette: Coding is boring, unless…
Мне не удавалось, как разработчику, задерживаться на одной работе больше двух лет.
Каждая новая работа — это отличный карьерный шаг, а высокая текучка работников присуща нашей сфере. Но мои бывшие работодатели не были особенно рады, что я уходил. Некоторые из них пытались удержать меня, но мне становилось так скучно, что у меня не оставалось выбора.
(Оговорка: мне везло, что я жил в местах, где работы для программистов было больше, чем программистов! Я понимаю, что возможность сменить работу доступна не всем).
Сейчас я соучредитель и технический директор компании Enki. Так что я несу ответственность за инженерную культуру. Часть моей работы — быть уверенным в том, что наши разработчики не сходят с ума от скуки, как это иногда случалось со мной в прошлом.
Мы с командой разработали стратегию против скуки и применили ее в нашей компании. И поскольку эта стратегия до сих пор хорошо работает, я хотел бы поделиться ей здесь.
В Enki нам повезло работать над трудной и интересной задачей. У нас есть много интересных штук для претворения их в код и множество занятных проблем, которые нужно решить. Поэтому, казалось бы, о какой скуке может идти речь? Но в начале её никогда и не бывает. Скука, как правило, нагнетается со временем, и поражает вас в самый неподходящий момент.
Вот почему мы заранее предлагаем решение, создавая культуру, которая спасет нас (постучим по дереву!) и сделает так, чтобы никогда не становилось скучно.
Хочу поделиться с вами горячими клавишами, которыми пользуюсь или к которым пытаюсь привыкнуть в своей повседневной работе. В современных средах их количество может просто зашкаливать, но постепенное добавление новых сочетаний в копилку, способно значительно повысить вашу продуктивноть. Приведенные сочетания относятся к редактированию, навигации, рефакторингу и справедливы только для раскладки Default for XWin (Linux).
Начинаем разработку чата на Go. Со стеком технологий пока не определились, но для начала сделаем каркас на Go. Берем за основу стандартный пример и пробуем разобраться, что здесь к чему:
https://github.com/golang-samples/websocket/tree/master/websocket-chat
Вводим 3 структуры Message, Client, Server, которые определяют сервер, клиента со стороны сервера и сообщение.
Сообщение определено структурой:
type Message struct {
Author string `json:"author"`
Body string `json:"body"`
}
func (self *Message) String() string {
return self.Author + " says " + self.Body
}С сообщением все совсем просто… Так, что перейдем сразу к клиенту.
UPD: 8 января 2017 статья переписана. теперь она понятнее и носит более общий характер, без углубления в одну из моделей понятия
Главное в статье для неосиляторов: творчество — это создание качественно новых материальных и нематериальных ценностей. Что сводится к постановке качественно новых проблем, задач, их решению, а так же созданию качественно новых способов (алгоритмов) решения уже решённых задач. В посте будет рассматриваться модель творчества, компиляция материалов нескольких авторов. Для умеренных осиляторов презентация. Остальных приглашаю в статью.
Множество статей и книг посвящено тому, как правильно проектировать API, но едва ли кто-то затрагивал тему постоянно меняющихся (гибких) API. Динамично развивающаяся компания зачастую выпускает по несколько релизов в неделю, а иногда и в день. При этом для добавления новых функций необходимо постоянно вносить изменения в существующее API. В этой статье мы расскажем о том, как мы в Badoo решаем эту задачу, какие подходы и идеи мы используем в своей работе.
Это седьмая статья из цикла «Теория категорий для программистов». Предыдущие статьи уже публиковались на Хабре:
За понятием функтора стоит очень простая, но мощная идея (как бы заезжено это ни прозвучало). Просто теория категорий полна простых и мощных идей. Функтор есть отображение между категориями. Пусть даны две категории C и D, а функтор F отображает объекты из C в объекты из D — это функция над объектами. Если a — это объект из C, то будем обозначать его образ из D как F a (без скобок). Но ведь категория — это не только объекты, но еще и соединяющие их морфизмы. Функтор также отображает и морфизмы — это функция над морфизмами. Но морфизмы отображаются не как попало, а так, чтобы сохранять связи. А именно, если морфизм f из C связывает объект a с объектом b,
f :: a -> bто образ f в D, F f, связывает образ a с образом b:
F f :: F a -> F b(Надеемся, что такая смесь математических обозначений и синтаксиса Haskell понятна читателю. Мы не будем писать скобки, применяя функторы к объектам или морфизмам.)
