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

Да, я ноунейм из интернета, очень начинающий редактор, просто делюсь своим мнением. И вот спонтанно, под настроение, решил порассуждать о самом, пожалуй, влиятельном писательском дуэте нашей фантастики.

Проработав фулстек разработчиком около 10 лет, я заметил одну странность.

Я ни разу не встретил не MVC веб-фреймворк. Да, периодически встречались вариации, однако общая структура всегда сохранялась:
​

• Codeigniter — мой первый фреймворк, MVC
• Kohana — MVC
• Laravel — MVC
• Django — создатели слегка подменили термины, назвав контроллер View, а View Template'ом, но суть не изменилась
• Flask — микрофреймворк, по итогу все равно приходящий к MVC паттерну
  ​

Конечно, с моим мнением можно поспорить, можно продолжить перечислять, однако суть не в этом.

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

Начнем со сказки. Жил да был глагол( swim, jump, run… ), решил сменить пол, то бишь стать существительным. И превратился в герундий. И глаголом не остался, и существительным не стал. Получилось что-то непонятное, нечто среднее, скажем так: swimming, jumping, reading.

Мы это понимаем примерно так

swimming -плавание,

reading -чтение

jumping -прыжки.

То есть jumping -прыгание, как то язык не поворачивается сказать.

Но все эти примеры объединяет то, что они обозначают некий процесс. Какое-то занятие, полезное или не очень. Еще примеры в студию:

speaking, listening, reading, writing.

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

Данная статья выражает мое личное мнение, основанное на опыте подготовки и сдаче экзамена на сертификат PMP (Project Management Professional) от Project Management Instittute.

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

Получить всю официальную информацию, вы можете на сайте www.pmi.org

О чем это мы

Сертификат PMP от Project Management Institute (pmi.org) является на сегодняшний день самым признаваемым по всему миру сертификатом подтверждающим квалификацию специалистов в сфере управления проектами. Наличие данного сертификата будет несомненным плюсом при рассмотрении вашего резюме потенциальным работодателем.

Иногда вещи находят себе применение неожиданно и не в том, для чего их задумывали. 

В 1960-е годы Кен Томпсон — легенда программирования — написал компьютерную игру Space Travel для операционной системы Multics. Система была проектом компании Bell Lab, где он работал вместе с Денисом Ритчи. Позже проект закрыли, и чтобы продолжать играть в свою Space Travel, Томпсон решил портировать ее на компьютер PDP-7. Инструменты, которые он создал для порта, затем легли в основу операционной системы Unix. 

Томпсон написал в одиночку первые три версии. Для Unix был нужен системный язык — так появился B. Позже Денис Ритчи, коллега и друг Томпсона, подхватил разработку и написал язык C. Вот так в основе почти всего, на чем построены современные технологии, лежало желание поиграть в компьютерную игру и пет-проекты для забавы.

Кен Томпсон построил блестящую карьеру исследователя в области computer science. В середине 2000-х он устроился в Google, где вместе с Робом Пайком и Робертом Грейсмером создал Golang — один из самых популярных языков последнего времени.

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

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

Есть миф, что в крупные ИТ-компании берут на работу специалистов, которые умеют всё и готовы работать на любых проектах. Мы так не считаем, и поэтому решили рассказать, как учатся наши сотрудники из Центра управления данными.

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

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

За пять лет работы в «Аркадии» — компании-разработчике программного обеспечения на заказ, где я работаю тестировщиком, — мне довелось поучаствовать в самых разных проектах. Большая часть из них была связана с веб-разработкой, меньшая — с мобильной. Некоторые проекты длились более года, другие были краткосрочными (полгода или даже пару месяцев). Менялся и размер команд: от трёх до трёх десятков человек.  

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

«Забудь дедукцию, давай продукцию», —  эту формулу я усвоил сразу после окончания института. Тогда я ещё был финансистом и мир науки и образования меня буквально выкинул в мир бизнеса. Я ждал матриц, проектных структур, менеджмента строго по Мескону и Хедоури, а получил «твою мать, какого х** бюджет не сводится, давай, подрисуй цифирь и отправим это уже главнюкам». Вооот, а это была компания на 120 человек с чистой прибылью в пару сотен миллионов. Это было начало 2008 года, который компания пережила, сократив 23 человека. А вот декабрь 2014-го стал последним месяцем существования всего холдинга. Я, уже большой чувак, понимал, что это всё — результат череды управленческих ошибок. К тому времени я работал сисадмином в ИТ-компании и был уверен, что здесь всё будет круто. Сменив три ИТ-компании, я понял, что айтишники при всей инженерной стройности управляют и развиваются без вектора. И знаете, сейчас меня это тревожит.

Короче, я вам щас про реальный менеджмент затру. Субъективно.

Заголовок, конечно, из детства и сразу вспоминаются бравые бурундуки. Эти самые бурундуки всегда и всем помогали и вообще молодцы.

Проблема лишь в том, что реальность не мультик, и Чип и Дейл устали спасать всех. Устали постоянно напоминать, что нужно ввести работу с клиентами Заказчика, звонить/приезжать и убеждать, что нужно менеджеров всё-таки мотивировать работать, а не порастать мхом.

Насколько пользователь должен быть уверенным в себе? В своих навыках работы на компьютере? Включил и работает? Или больше? И насколько больше?

В современных реалиях владение компьютером для работников, трудящихся в офисе – вроде как обязательный навык. Но непонятно, как его померить. Давайте посмотрим, насколько пользователь уверен в том, что он уверенный пользователь.

Маленькая ремарка – от сотрудников обычной компании не требуется настраивать многоуровневую сеть или проводить замену оборудования при поломках и модернизации оного.

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

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