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

Денис взялся за имидж, Наталия Бакшаева за связь с министерством и IT-ассоциацией ЧР. Михаил Киселев (Megaputer Intelligence) пригласил именитых специалистов.

Алексей Радченко (cheb.ru) любезно предоставил спецкамеру для профессиональной съемки. Владимир Сивов (InfoLink) помог с волонтерами (Глеб, спасибо за помощь с презентациями).

Опубликовали анонс в facebook, появились и другие спикеры.

Безуспешно пытались привлечь бизнесменов из электрокластера ЧР. За время организации меропрятия выслушал множество сомнений в успехе, особенно касаемо заинтересованности аудитории. Звонки в…

Так случилось, что последние 10 лет я постоянно собеседую и нанимаю людей. В интенсивное время через меня проходило 100–150 кандидатов в год, в слаботочные 30–50. Сейчас не проходит и недели, чтобы мне не приходилось кого-то собеседовать. Да, сегодня это в основном программисты, но раньше были люди совсем других профессий.

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

До нашей эры

Первые сотрудники которых мне пришлось отбирать были монтажники слаботочных сетей.

В начале 2000-х благодаря поддержке Павла Якимова я создал интернет провайдера ORIONET. Всю работу — разработку логотипа, макетов рекламы, прокладку кабеля, подключение абонентов, настройку коммутаторов, Unix-серверов и заключение договоров…

В последнее время остро ощутил нехватку внутренних ресурсов для эффективного принятия решений.

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

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

Появляется феномен “ничего у меня не спрашивайте, я экономлю топливо мозга для более важного”

В этом ключе становится понятна необщительность и закрытость некоторых…

Сегодня пришла такая задачка:

И в списке чатов и в открытом чате.
Формат:
Сегодня в 00:00
Вчера в 00:00
20 июля в 00:00
1 января 2014 года в 00:00

И в довесок:

не считаешь ли нужным вынести в бекенд (API), чтобы унифицировать среди всех клиентов?

Во-первых. API (backend) ни в коем случаи никогда не должно отдавать даты в форматированном виде. Потому что:

1. Формат презентации даты зависит от локали пользователя и настроек клиентского приложения, которое эти даты показывает. Если клиентское приложение имеет большое разрешение экрана, можно показывать даты текстом, если маленькое, то только цифрами. …

Раньше часто спорили на тему какой код можно назвать хорошо читаемым. Какие-то нотации, rubocop-ы, code metric-и, можно упаковывать в одну строку или нет, пробелы или табы и тп.

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

Со временем все улеглось и для себя определил один наиболее важный критерии читаемости. Называю его принцип “салфетки”, вероятно авторство не моё.

Звучит он так:

Код хорошо читаем тогда, когда из его прочтения можно восстановить задачу по которой он написан.

А…

Одна из худших практик в примерах из учебников по Ruby On Rails это передача данных из controller во view через instance-перменные. Например так:

# Так делать плохо
#
def show
 @user = User.find params[:id]
end# А так еще хуже
#
before_filter do
  @user = ...
end

Почему плохо:

1. При каскадном рендеринге вьюх (использовании паршелов) вы никогда не знаете где появилась эта переменная и не знаете для кого она предназначена
2. Лишаетесь гибкости при переиспользовании view/partial
3. Не имеете явной передачи парметров во view
4. Фактически получаете глобальную переменную, которые, как все знают являются воплощением ада, получаете к ней не контроллируемый доступ их…

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

Так как опыта в управлении небыло никакого пришлось учиться: курсы, тренинги, местячковый MBA. Программерский навык обобщать и экстраполировать пригодился — быстро понял что все бизнес-тренеры говорят об одном и том-же. И начинают они, в первую очередь, с личностных корректировок и отработки навыка постановки целей. Личных, коллектива, компании.

Сначала учимся цели определять, а потом их достигать.

А как отличить цель от фантазии или мечты? Ну вот бредится мне что-то, например, хочу много пользователей на…

Вы еще боитесь брать на работу новых сотрудников, потому что они научится и уйдут? Не бойтесь, на вашей стороне Трудовой Кодекс.

Должен будешь

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

Как ни странно избежать этого достаточно просто законным способом — включить в трудовой договор пункт запрещающий сотруднику существенный период (3–4 года) работать в сфере деятельностью вашей компании и заключить ученический договор, с выплатой стоимости не отработанного обучения. …