Давным-давно я написал статью на Хабр с названием «Интенсивность важнее тщательности» про то, что лучше увеличить количество попыток сделать что-то, чем продолжительность одной попытки. Теперь я хочу дополнить эту мысль.



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

Блоки информации (chunks)

Чтобы свободно пользоваться новыми знаниями, к ним нужно привыкнуть. А привычка, как известно, дело времени. В книге Learning How to Learn (или на замечательном курсе на Coursera) блоки информации называются chunks, и в курсе рассказывается про их формирование. На это уходит время, которое на практике нельзя существенно ускорить.

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

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

15 марта, Санкт-Петербург — ODS SPB Meetup #5

28 марта, Москва — Scalability Meetup #7

А также на JPoint и Saint Highload

И снова привет!

Коллеги, в последний день января мы запускаем курс «MS SQL Server разработчик», в связи с чем у нас прошёл тематический открытый урок. На нём мы поговорили о том, как MS SQL Server выполняет запрос SELECT, обсудили, в каком порядке и что анализируется, а также немного погрузились в чтение плана запроса.

Преподаватель — Кристина Кучерова, архитектор модели данных в Сбербанке России.

Вот уже пару лет я живу в США, развиваю два собственных проекта и сегодня решил поделиться опытом. Мне на глаза часто попадаются статьи с рассказами о том, как классно делать бизнес в США, авторы которых не рассказывают о возможных сложностях на этом пути. В итоге у многих может сложиться чересчур идеализированное представление о том, как они приедут в Кремниевую Долину со своим стартапом менять мир.

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

От переводчика: сегодня публикуем для вас статью Праякты Татавадкар, она разработчик с небольшим стажем, но знания и опыт позволили ей получить работу в Google (со второй попытки), стать членом команды разработчиков YouTube.

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

В своём введении к книге Working, знаковой устной истории работы 1974 года, Стадс Теркель поставил осмысленность на ту же ступень, что и финансовую компенсацию, в деле мотивации американских работников. «Работа – это поиск ежедневного смысла в той же мере, как и поиск ежедневных средств к существованию, она нужна для признания в той же мере, как и для наличных, для удивления, а не для безразличия», — писал он. Среди кучки счастливцев, встреченных им, наслаждавшихся своей работой, Теркель приметил общую тенденцию: они ценили «осмысленность работы выше награды, получаемой от зарплаты».

Прошло уже больше 40 лет, и целые горы исследований поддержали заявление о том, что американские работники ожидают чего-то более интересного, чем зарплата, в ответ на свой труд. Текущие уровни компенсации слабо коррелируют с удовлетворением от работы. И наоборот, с 2005 года важность осмысленности в выборе работы постоянно растёт. «Смысл – это новые деньги», как заявили в статье в HBR в 2011 году. Почему же не растёт число компаний, предпринимающих конкретные шаги для того, чтобы сконцентрировать свою культуру на создании смысла?

Многие из нас сталкивались в своей работе с СУБД. На текущий момент базы данных в том или ином виде окружают нас повсюду, начиная с мобильных телефонов и заканчивая социальными сетями, в число которых входит и любимый нами хабр. Реляционные СУБД являются наиболее распространенными представителями семейства СУБД, и большинство из них являются транзакционными.
В институте нас заставляли заучивать определение ACID и стоящие за ним свойства, но почему-то стороной обходились подробности реализации этой парадигмы. В данной статье я постараюсь частично заполнить этот пробел, рассказав о MVCC, которая используется в таких СУБД как Oracle, Postgres, MySQL, etc. и является весьма простой и наглядной.

Дорогой Хабр, мы решили поделиться заметками и нашим базовым рецептом о приготовлении проектов в Sparx Enterprise Architect. Причем под проектом мы подразумеваем создание какой-либо информационной системы. Впереди вас ждет рассказ о том, как у нас все организовано – примеры диаграмм, структура проекта в Enterprise Architect, немного о требованиях, проектировании и постановках на разработку.

Источник

Перед тем, как ответить на вопрос «Как измерить успех?», надо понять, что значит «успех» именно для вас. Для Dev и Ops определение успеха отличается. Для Dev успешный проект полностью проходит тестирование. Для эксплуатации — мониторинг. Тестирование и мониторинг нужны, но тесты никогда не дают 100% покрытия проблемы, а ответа 200 от HTTP недостаточно, чтобы быть уверенным в том, что система хорошо работает. Leon Fayer на РИТ++ отстаивал точку зрения, что DevOps платят не за то, чтобы все метрики в мониторинге были в зеленой зоне. Платят за то, чтобы пользователи были довольны. Если недовольны — бизнес теряет деньги, и никого не волнует, что все зеленое.

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

О спикере: Leon Fayer родился в когда-то дружественной республике, но вырос в США. Начал заниматься программированием очень много лет назад, и за это время работал программистом, менеджером — кем только не работал. Участвовал в стартапах — некоторые были более удачные, а некоторые не очень.

Много лет Леон работает в OmniTI. Эта компания специализируется на разработке масштабируемых систем, поэтому Леон имеет уникальную возможность проектировать и строить системы для самых посещаемых сайтов в мире — Wikipedia, National Geographic, White House, MTV и т.д.

У меня есть некоторый опыт в реализации систем на базе микросервисной архитектуры и я хотел бы поделится вопросами (и ответами), которые возникают при реализации подобных проектов. К сожалению, я не имею права распространяться о проектах в которых я участвовал, поэтому я выдумал собственный сферический проект в вакууме. В этом проекте нам встретится множество стандартных проблем.

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

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

Чему уже научились сверточные искусственные нейронные сети (ИНС) и как они устроены?

1. Предисловие

Такие статьи принято начинать с экскурса в историю, дабы описать кто придумал первые ИНС, как они устроены и налить прочую, бесполезную, по большей части, воду. Скучно. Опустим это. Скорее всего вы представляете, хотя бы образно, как устроены простейшие ИНС. Давайте договоримся рассматривать классические нейронные сети (типа перцептрона), в которых есть только нейроны и связи, как черный ящик, у которого есть вход и выход, и который можно натренировать воспроизводить результат некой функции. Нам не важна архитектура этого ящика, она может быть очень разной для разных случаев. Задачи, которые они решают — это регрессия и классификация.

2. Прорыв

Что же такого произошло в последние годы, что вызвало бурное развитие ИНС? Ответ очевиден — это технический прогресс и доступность вычислительных мощностей.

Приведу простой и очень наглядный пример:

Илья Космодемьянский ( hydrobiont )

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

Недавно на хабре уже было опубликовано описание интеграции PostgreSQL и MSSQL. Но, деталей там категорически не хватало. Посему, цели сей публикации следующие:

• расширить и углубить общедоступную информацию о FDW для MSSQL называемом tds_fdw: рассказать о разнице в мажорных версиях и описать базовые проблемы совместимости;
• рассказать о возможностях оптимизации запросов, использующих внешние таблицы;
• затронуть тему кэширования внешних данных в материализованных представлениях;
• сказать пару слов об экзотических подходах к интеграции PostgreSQL и MSSQL.

В предыдущей статье мой коллега Дмитрий Васильев описал настройку интеграции PostgreSQL с MySQL и описал, как более эффективно выполнять некоторые запросы.

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

Когда я был ещё первокурсником, то познакомился с другим студентом, который утверждал, что может писать код на любом языке программирования, который я смогу назвать. Я был несколько шокирован и ответил подначкой:

— Что, даже на том нечитаемом эзотерическом языке, где есть всего пара команд, которые едва-едва симулируют машину Тьюринга?
— Да, этот язык называется brainfuck. Я знаю brainfuck.

И это был не трюк — мы проверили. Я называл известный мне язык программирования, он тратил пару минут в Интернете на то, чтобы освежить свои знания по нему — и был способен писать на этом языке работающие алгоритмы. Я никак не мог понять этого. Ему, как и мне, было тогда около 18 лет — как он мог в этом возрасте знать все эти языки?


Интерпретатор brainfuck, написанный на brainfuck

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

Сегодня я советую своим студентам «постараться изучить все языки программирования». Подумайте сами — ведь эта идея лучше, чем все вот эти «В этом году я выучу Go! Ой, нет, теперь говорят что в моде Rust — выучу лучше Rust! Или Swift ...». Просто выучите все — не ошибётесь. А эта статья, возможно, вам в этом немного поможет.

Многие пользователи СУБД PostgreSQL знают, что сервер во время своей работы собирает разнообразную статистику, но не все знают, что ее полезно анализировать и как ее извлекать для этого. В этом небольшом тулките собраны несколько полезных запросов, дающих некоторое представление о том, как использовать это «скрытое знание», которое постоянно копится. Эти запросы можно использовать для мониторинга состояния PostgreSQL (ручного или с помощью плагинов для систем мониторинга вроде Nagios, Cacti или Zabbix), для поиска узких мест в работе сервера и многих других подобных задач. Помните, что это лишь верхушка айсберга; в документации можно найти описания нескольких десятков системных представлений, которые также могут быть полезны администратору PostgreSQL.

Дисклеймер от автора (автор — девушка): Я не разрабатываю движки баз данных. Я создаю веб-приложения. Я участвую в 4-6 разных проектах каждый год, то есть создаю много веб-приложений. Я вижу много приложений с различными требованиями и различными потребностями хранения данных. Я разворачивала большинство хранилищ, о которых вы слышали, и несколько, о которых даже не подозреваете.

Несколько раз я делала неправильный выбор СУБД. Эта история об одном таком выборе — почему мы сделали такой выбор, как бы узнали что выбор был неверен и как мы с этим боролись.Это все произошло на проекте с открытым исходным кодом, называемым Diaspora.

Крис Касперски на RSA Conference 2015. Источник: хакер.ру

Говорят, что незаменимых людей нет. По большей части это действительно так, но есть и исключения. Например, если говорить о Николае Лихачеве, которого весь мир знает, как Криса Касперски, то здесь утверждение о незаменимости дает сбой. В ИТ-сфере этот человек сделал очень многое, о чем можно судить хотя бы по печатному «наследию»: Касперски оставил после себя больше 20 книг и 500 статей. Он был настоящим хакером, в изначальном понимании этого слова. То есть человеком, который прекрасно разбирался в том, как и что работает в ИТ.

Собственно, информационными технологиями он стал заниматься очень рано — с начальных классов, сразу после появления первого компьютера, который носил гордое название «Правец 8Д». По сути, это клон британского компьютера Oric Atmos, причем инструкция была на болгарском языке. Тем не менее, Крис (тогда еще Николай) быстро со всем освоился, написав свою первую игру. В ней пользователь должен был поймать рыбку. Графики здесь не было, ее роль играли символы. В центре экрана находился рыбак в виде знака вопроса, а рыбка отображалась при помощи нолика и знака «больше». Ловить рыбу нужно было, нажимая на пробел.

-Я хочу устроить панику, понятно?
-Ты там бойню устроишь, а не панику.
«Большой куш»

В течение уже достаточно долгого времени мне попадаются на глаза посты, статьи и даже целые книги, задача которых — донести до читателя советы о том, как правильно делать Скрам. Все они, в общем-то, однотипны и построены на предположении, что большинство людей некорректно понимают предлагаемые практики, их назначение и важность. В этих источниках активно доказывается, что Скрам все-таки работает, говорится о принятии ценностей, о перестроении мышления на уровне компании, о тонкостях организации митингов и прочих нюансах, которых по итогам каждый раз набирается вагон и маленькая тележка. Судя по всему, проблема действительно существует, ведь даже Кен Швабер и Джеф Сазерленд описывают Скрам как “легковесный, простой в понимании и сложный в овладении” [1]. Но только ли дело в практиках? Может быть, люди не понимают саму суть Скрама? Когда что-то начинает приносить серьезные деньги, то не секрет, что именно прибыль становится путеводной звездой этого корабля. Может быть все эти тренинги, сертификации и спешно переучивающиеся в скрам-мастеров менеджеры проектов затмили собой изначальный посыл? Вполне вероятно. Но так ли это? Данный опус — это попытка взглянуть на проблему под немного другим углом, с точки зрения больше технической, чем какой-либо еще.

Несколько вещей гарантированно будут увеличиваться со временем: расстояния между звёздами, энтропия вселенной и бизнес-требования к ПО. Многие статьи пишут «Не усложняйте!», но не пишут почему или как это сделать. Вот вам 10 ясных примеров.

1. Инженерам виднее

Мы, инженеры, считаем себя умнейшими людьми. Ну, поскольку мы создаём разные штуки. И эта ошибка часто приводит к оверинжинирингу. Если вы спланировали и построили 100 модулей — Бизнес всегда попросит у вас 101-ый, о котором вы никогда не задумывались. Если вы соберётесь с силами и решите 1000 проблем — они придут к вам и выложат на стол 10 000 новых. Вы считаете, что у вас всё под контролем, а на самом деле вы даже не представляете, в каком направлении вас завтра поведёт дорога.



За мои 15 лет работы программистом я ещё ни разу не видел, чтобы Бизнес выдал законченные и стабильные раз и навсегда требования к ПО. Они всегда меняются, расширяются. И это природа бизнеса, а не ошибки людей, управляющих им.

Мораль: Казино (бизнес) всегда побеждает.