Никогда не читайте книги для самообразования просто так, без практики. Это самое плохое, когда человек прочитывает кучу книг, а затем пытается устроиться работать продакт-менеджером, размахивая книжными знаниями. Таких соискателей сразу видно. И замечательно, если человек на работе начинает развивать себя как продакт-менеджер. Очень часто проджект-менеджеры ведут себя как продакты. К примеру, тестировщики начинают читать полезные книги, в отличие от разработчиков, которые сидят и пишут код, ничего не читая о тех же гибких методологиях.

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

Товарищи инженеры, как и было обещано в анонсе, половина лекций (а это 51) уже доступны для просмотра на ютюбе и я продолжу их записывать в 2019 году. Часть из нужно будет перезаписать, потому, что в первых лекциях не самый лучший звук и потому, что очень простые темы у меня пока не очень хорошо получаются. Лучше вышли сложные и актуальные темы, которые мне и самому более интересно рассказывать. Я бы не сказал, что это курс для начинающих, скорее, это курс для тех, кто уже знает синтаксис. За это время поступило множество предложений, как улучшить способ подачи материала: делить на более короткие лекции, подготовить задачи для практического освоения, записывать семинары и ответы на вопросы студентов, добавить в программу разбор целого ряда спорных и холиварных тем. Но не все сразу, я и так посвящаю этому треть жизни.

Масштабирование СУБД – это непрерывно наступающее будущее. СУБД совершенствуются и лучше масштабируются на аппаратных платформах, а сами аппаратные платформы наращивают производительность, число ядер, памяти — Ахиллес догоняет черепаху, но все еще не догнал. Проблема масштабирования СУБД стоит во весь рост.

Компании Postgres Professional с проблемой масштабирования довелось столкнуться не только теоретически, но и практически: у своих заказчиков. И не раз. Об одном из таких случаев и пойдёт речь в этой статье.

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

– Добрый день, Станислав Сергеевич! Проходите, пожалуйста!

– Здравствуй, Катенька! Прохожу, прохожу…

– Чай, кофе?

– Ну… Не знаю я. Ничего, наверное.

– Хорошо, как скажете. Я немного волнуюсь, если честно – в первый раз через эту процедуру проходит программист…

– Ну, не клизму же ставить будете, Катюш. Не бойтесь, я вас не съем.

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

Источник

Осенью 2016 года нам с коллегой поручили улучшить документацию и контент в моей бывшей компании. Мы потратили год на все виды документации: справочник по API, руководства, учебные пособия, сообщения в блогах. До этого я 5 лет писала доки, но официально не обучалась этому. Но и неопытной меня нельзя назвать: кроме документирования API для проектов и стартапа, я ещё преподавала Python Flask на семинарах во время учёбы на последних курсах в университете. Но сейчас выпала возможность сосредоточиться только на любимом деле: помогать специалистам всех уровней через техническую документацию.

В этом году я многому научилась в сообществе Write The Docs, у других провайдеров API, а также методом проб и ошибок. В прошлом году я поделилась опытом в докладе «Что мне хотелось бы знать о написании документации» на конференции API Strategy and Practice в Портленде. Эта статья — обзор полученных знаний.

Английская грамматика – удивительна своей простотой. Её очень сложно не любить: почти всё логично, структурировано, понятно, если знать (конечно). Это не русский, где можно что угодно сказать как угодно, но и в этом есть свой шарм. Поэтому мне всегда кажется, что людям с математическим складом ума природа просто кричит в ухо, что английский надо учить и для них это просто. Полно конечно всяких исключений, куда без них, но в общей массе всё логично.
Допустим, решились, нашли какую-то мотивацию. Так как же начать, с чего подойти? С алфавита? С неправильных глаголов? С произношения? Можно как угодно подходить, но, если ваша цель заговорить, правильнее всего будет подойти к преподавателю. Если к преподавателю лично подойти не можете, подойдите сюда.

Нас часто спрашивают, какие книги стоит почитать тем, кто делает первые шаги в сфере информационной безопасности? Наша команда экспертов по тестированию на проникновение составила подборку книг, которые помогут освоить практические вопросы ИБ.

«Талант выигрывает игры, а команда чемпионаты». Так однажды сказал Майкл Джордан и оказался прав. Любое успешное решение, будь то выигранный чемпионат или релиз нового продукта в IT команде, достигается усилиями каждого отдельного человека. С чего начинается командный путь к успеху?

Про обратную связь, которая вызывает желание убивать

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

1. “Это непрофессионально...

Привет, Хабр!

Меня зовут Игорь, я Android-разработчик в команде Trinity Digital. Сегодня я хочу рассказать о классном инструменте — Google Pay API.



Итак, если в вашем приложении можно совершать покупки, и при этом вы используете не In-app Billing (за процессинг отвечает не Google Play), то скорее всего среди вариантов оплаты у вас есть и “Оплата картой”. А это значит, что вам каждый раз приходится отправлять пользователя вводить данные карты или на красиво сверстанные экраны с картой, или на веб-сайт вашего провайдера платежных сервисов (далее — payment processor). Уже посчитали сколько действий придется совершить пользователю, чтобы оплатить заветный заказ? Ага, а теперь представьте, что он сможет выполнить то же целевое действие всего в два тапа. Мы тоже представили и подумали, а почему бы не дать пользователям такую возможность? Основные условия успеха — продавец быть зарегистрирован в Google и payment processor должен сотрудничать с Google.

На Geektimes я часто встречаю и с удовольствием читаю посты из серии DIY. Решив сделать небольшой вклад в копилку ценного опыта, собранного здесь, я собираюсь подробно описать процесс создания клиента для веб, базирующегося на серверах «Линия».

Система видеонаблюдения «Линия» предоставляет открытое API, и разработчики заявляют, что на его основе можно написать собственный клиент для просмотра видеоархива и камер онлайн. Также при желании можно реализовать такие функции, как добавление событий в архив, наложение OSD поверх видео. Описание всех возможностей представлено в спецификации на официальном сайте.

Данная статья — это реальный пример, как я, пользователь с начальными знаниями JS, HTML, написал собственное приложение, реализующее базовые принципы работы с серверами «Линия» через встроенный web-сервер.

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



Мозг всегда пытается понять мир, сравнивая предыдущее восприятие визуальных образов и соединяя точки. У него есть свой «странный» способ восприятия очертаний и формы, группировки информации, заполнения пробелов для создания общей картины.

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

Добрый день, хабрасообщество! Сегодня я хотел бы рассказать о волшебном и чудесном проекте компании Тензор — удаленном помощнике. Это система удаленного доступа, связывающая миллионы клиентов и операторов в рамках общей клиентской базы СБИС. Удаленный помощник уже сейчас тесно интегрирован с online.sbis.ru. Каждый день мы регистрируем более десяти тысяч подключений и десятки часов сессионного времени в сутки.В этой статье мы расскажем о том, как мы устанавливаем p2p соединения, и что делать, если этого сделать не удается.

Мы с большим любопытством заглянули в R&D-отдел наших давних партнеров — компании Стриж, которая сама разрабатывает и производит в России базовые станции, конечные устройства IoT, протоколы передачи и ПО. Большая часть наших вопросов касалась организации процесса разработки и трудностей, с которыми они сталкивались.

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



С тех пор большинство настольных браузеров следуют тенденции и используют фавикон тем или иным способом. Это очень просто, не так ли? Создать маленькую картинку и добавить в любой интернет-проект, чтобы сделать его «завершённым». Ничего сложного.

Последние пару лет мы видим быстрый прогресс по разным направлениям в борьбе со сенесцентыми клетками. Недавно компания UNITY Biotechnology сделала громкое заявление, и продление жизни за счёт удаления сенесцентных клеток было продемонстрировано у мышей. Это прекрасное время для SENS, Strategies for Engineered Negligible Senescence, ибо одна из важных технологий омоложения организма, которую организация продвигала и поддерживала более десятилетия, – сейчас активно движется в направлении клинических испытаний. Это позволяет привлечь ранее недоступное венчурное финансирование и повышает информированность общества о возможности лечения старения.

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

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

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

Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.

Я не хотел писать заметку про Petya/Nyetya/NePetya и другие названия вредоносного кода, который в начале недели в очередной раз заставил содрогнуться мир по версии многих СМИ. Мое нежелание было продиктовано двумя причинами. Во-первых, именно нас, то есть компанию Cisco и ее подразделение Talos (про него я уже упоминал тут, но, видимо, придется рассказать чуть больше, что это за подразделение), пригласили участвовать в расследовании происходящего в Украине, а писать о результатах следствия до его окончания мы, понятно, что не имеем возможности. Да и после окончания следствия не все его результаты будут опубликованы. Во-вторых, надо признаться, что я не разделяю того ажиотажа вокруг вредоносного кода, названного нами Nyetya, который последние дни только подогревается разными публикациями и заявлениями.

Что в нем такого уникального, что его отличает от других вредоносных программ и от того же WannaCry? Почему никто так много не пишет про Jaff или BitKangoroo, которые распространялись в то же время, что и WannaCry и использовали схожие методы? Почему никто не снимает репортажей и не обсуждает Untukmu, Shifu, Blackshades или тот же Locky, который заразил больше компьютеров чем WannaCry, Petya, Misha и Nyetya вместе взятые? Почему специалисты по ИБ с серьезным лицом обсуждают, кто раньше из них отреверсил “Петю” и кто быстрее всех распространил индикаторы компрометации? Кто-то называет 30 минут, кто-то 37 минут, кто-то “проснулся” только через несколько часов…