Открыть список
Как стать автором
Обновить
18
Карма
0.3
Рейтинг

Пользователь

Нужна ли сертификация для бизнес-аналитика?

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

Что входит, что где лучше, куда лучше например усилия Product Manager в стартапе, а куда бизнес-аналитику в суровом Enterprise

Как звезда бейсбола вложил в разработку игры $50 000 000 — и потерял всё

+1)
А еще взаимодействие с разными типами игр. У mail.ru были статьи, где они хорошо разбирали сегментацию и подгонку игры под разные типы игроков

habr.com/ru/company/mailru/blog/274263
habr.com/ru/company/mailru/blog/263839

Экономика игры это и стоимость привлечения игрока, и сколько денег он приносит, и виральность, LTV и т.д.

Как звезда бейсбола вложил в разработку игры $50 000 000 — и потерял всё

Есть отличная поговорка:
Когда встречается два человека: один с деньгами, другой с опытом, то тот, который с опытом — уходит с деньгами, а тот кто был с деньгами — уходит с опытом.

А истории 100 -> 400, это про истории когда кто-то заходит на рынок и с деньгами и с опытом. И судя по истории Шиллинг пришел в рынок с деньгами и без опыта)

Как звезда бейсбола вложил в разработку игры $50 000 000 — и потерял всё

Спасибо за статью. Кажется что все в мире любят иллюзии.

Ждать от бейсболиста успеха в геймдеве — тоже самое, что ждать от программиста успеха в бейсболе.

Давайте возьмём гениального программиста, дадим ему тренеров, массажистов, команду и будем ждать, что он выиграет чемпионат мира, олимпиаду или мировой турнир. Глупо?) А про бейсболиста, который вложил $50млн в революционную игру — не глупо?)

Это не означает, что спортсмен не может стать успешным предпринимателем. Конечно может. Только делают это успешные люди постепенно и последовательно, точно так же как и в спорте.

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

А тут, с наскока, не студия по выпуску маленьких игр, а сразу производство «революционной игры», $5млн в офис, лучшие таланты, нам нужные лучшие из лучших и т.д. Поэтому в целом результат предсказуемый.

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

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

Разочарованы в IT? RPA как основа IT архитектуры, которая победит Микросервисы

Согласитесь, что формулировка:
«Если у вас много легаси и у вас принято решение поддерживать его, то в рамках периода этой поддержки использовать RPA может быть разумно»
несколько отличается от
«RPA как основа IT архитектуры, которая победит Микросервисы»

P.S. Я вообще не сторонник микросервисов. И считаю, в 9 из 10 случаев переход на микросервисную архитектура вредит. А RPA в контексте очередной волшебной таблетки я считаю еще бОльшим злом. Сам подход RPA может быть ок, но вот подача этого подхода как «Основа архитектуры», которая «Решит вашу боль» — это откровенное вредительство и введение в заблуждение.

Разочарованы в IT? RPA как основа IT архитектуры, которая победит Микросервисы

Вот именно! Выиграть временно. То есть RPA — это временное решение. Согласен. Но согласитесь, что называть временное решение основой архитектуры — хреновая идея. Это как сказать, что антибиотики — это основа иммунитета, что капельница с глюкозой отлично подходящая в ряде случаев — основа правильного питания.

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

Разочарованы в IT? RPA как основа IT архитектуры, которая победит Микросервисы

Почитал еще несколько статей по RPA

Сама идея хорошая:
Что-то спарсить. Откуда-то быстро собрать данные.
Как «сесть на трубу процесса» для его изучения и оптимизации — отличная штука.
Шикарная штука для внедрения изменений: сели на процесс «сбоку», автоматизировали, поняли какие данные есть, каких не хватает, оптимизировали процесс, доказали бизнесу эффективность и передали в разработку.

Но вот только не надо говорить что роботы, которые через интерфейсы как боты взаимодействуют со старым неэффективным неудобным интерфейсом — это основа хорошей архитектуры. Если текущая команда не может хорошо справиться со старой архитектурой, то старая архитектура + роботы поверх этого всего — это смерть. После появления роботов вносить изменения станет вообще невозможно. Особенно если они сядут где-то на интерфейсы, где-то на API. И судя по всему еще и будут сделаны какой-то внешней командой или под управление внешних «консультантов по RPA».

Представим задачу:
Маленький европейский городок, очень узкие улочки, нет железных дорог, в радиусе 1000 км нет ни одного грузовика, и надо срочно перевезти 20 тонн в 30-килограммовых мешках.
И тут вдруг мы обнаруживаем, что в городке есть очень дружная тусовка автолюбителей. И они как раз собираются в автопробег в нужном направлении, и можно в каждый из автомобилей накидать мешков, и вся колонка отлично перевезет наш груз. Командный дух, польза для города, задача решена, не надо решать сложные вопросы с грузовиками, нет нагрузки на наш старенький мост 15 века, не будет перекрыта дорога для погрузки и вообще всё прошло на ура. Фанфары, салют, все молодцы, задача решена!!!

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

Вот и с RPA так же. Шикарное решение, чтобы быстро собрать данные, что-то проанализировать, собрать прототип, и выкинуть. И IMHO называть это основой IT архитектуры — это уже вредительство)

14 полезных инструментов, ускоряющих и упрощающих веб-разработку

Автору спасибо за статью.
Переводчикам спасибо за перевод.


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

Когда объектов не достаточно

Мой опыт показывает, что глаголы должны быть убраны из описания предметных областей.
Они всегда всё портят. Нужно оставить только один глагол: TO BE

Есть студенты.
Есть курсы.
Есть посещения студентом курса. (Это отдельный класс, а если речь про БД, то это будет таблица где будут например данные: id, student_id, course_id, date, time)
То есть нет никакого «Журнала посещаемости», который имеет записи. Есть просто ПОСЕЩЕНИЯ.

И тогда да, у вас у студента будут student.visits, у курса будут course.visits

И это всё прекрасно работает. Если вам хочется пересечения, то это уже отдельный объект/класс/таблица БД и т.д.

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

Как я принёс Ruby в ДомКлик

С Python интересная ситуация. Мне кажется в сообществе Python-разработчиков не очень модно занимать веб-разработкой. Data Science, AI, ML — вот трушные области работы для питониста. А в Ruby как: хочешь писать на Ruby — занимаешься веб-разработкой.

И поэтому (по-моему личному опыту) средний опыт питониста в веб-разработке ниже, чем у рубистов. И еще ниже, если речь идет о fullstack разработке. А именно о ней шла речь в статье. Ведь для того, чтобы хорошо разобраться в беке нужно время. А если потом еще добавить фронтовые webpack, postcss, linters, yarn, tree shacking, etc — то нужно еще больше времени.

И по-моему личному опыту, средний проект на Rails сделан лучше, чем средний проект на Django. Последние два проекта на Django, которые мне довелось смотреть были сделаны без git (точнее первичный git clone есть, а дальше вялые и брошенные попытки вести git c последним коммитом больше года назад), и все равно с диким хламом в репе (вроде node_modules, паролей, secrets), без тестов, без деплоя, с загрузкой кода по ssh и т.д.

Я в Rails проектах многое видел, но такого никогда не видел)

PHP коммьюнити в СНГ. Было плохо — стало хуже

Спасибо за статью. Такая ситуация не только в PHP.

В Ruby сообществе последнее время еще модно пилить все на микросервисы, переписывать все на монады, сервис-объекты, 12factorapp и т.д. Архитектура ради архитектуры, программирование ради программирования.

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


Google продвигает новый стандарт WebBundles — потенциально опасную для веба технологию «упаковки» веб-сайтов

Я только что проверил на этой странице:

При повторной загрузке страницы загружает
116kB из 6.9MB
Это 1,5%

Для новой статьи (которую я еще не читал) загрузилось со всеми картинками 800kB из 6.8MB
Это 11%

Оставшиеся 89% — это кеш.

Google продвигает новый стандарт WebBundles — потенциально опасную для веба технологию «упаковки» веб-сайтов

Конечно будет.

Сейчас cloudflare и браузер можешь закешировать вот такие запросы:
dr.habracdn.net/habr-web/js/chunk-vendors.c83286b7.js

Сервер Хабра отдает один раз.
Сервер CDN кеширует статику.
Браузер скачивает этот js chunk 1 раз.

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

А еще сервер хабра отдал 1 раз, CDN закешировал и отдал пользователям 1 млн раз.
А если пихать это все в архив, то пользователи скачают 3-5 млн раз этот JS chunk.
И этот объем придется отдавать серверу.

Поэтому я не очень понимаю, как вообще это все можно провернуть.
Тысячи и миллионы сайтов рассчитаны на то, чтобы кешировать статику и делают это на разных уровнях: сервер, nginx, CDN, браузер, etc.

Как отказаться от этого кеширования в вебе — я не понимаю.

Google продвигает новый стандарт WebBundles — потенциально опасную для веба технологию «упаковки» веб-сайтов

Google решил убить Cloudflare?)

Но на самом деле мне кажется, что это задачка нереальная, потому что отвалится вся система кеширования (картинок, js, css). Такой рост объема данных «интернет» просто не переварит.

Если я заблуждаюсь — поправьте меня пожалуйста.

Интервью с Дарреном Мерфом, руководителем удаленной работы в GitLab

1) Я знаю коллегу, который устроился в gitlab, и спустя несколько месяцев снял себе место в коворкинге. Естественно рядом с домом. Ходить он туда не обязан, и летом и во время отпуска он его не оплачивает.

2) Мой друг в 2016м устроился на удаленку в голландскую компанию. Менеджером по обработке заказов. Не разраб, и ЗП не космическая. Компания занимается доставкой своих приборов в РФ и им нужны тут сотрудники. Большинство из них на удаленке. Так вот компания: оплатила новый ноут, 2 монитора, стол под все это, принтер, кресло. Стол/кресло можно было выбирать самому и бюджет был на то, чтобы выбрать себе лучшее геймерское кресло. Еще раз напомню — это просто менеджер по работе с клиентами и обработке заказов. А да, еще компания оплатила билет в Нидерланды, проживание, командировочные на 2 недели обучения, сразу после трудоустройства.
Как вы думаете мой друг все еще работает в этой компании? Да)

Удаленка не означает безразличное отношение к сотруднику и его условиям труда.

P.S. был случай в моей карьере, когда я привез свое собственное кресло в офис, потому что офисные были такие дерьмовые, что уж лучше на своем.

Приглашая опытного разработчика, вы не покупаете, а продаёте

Еще раз спасибо за статью! Очередной раз поделился ей и это статья помогла улучшить описание вакансий)

C++ быстрее и безопаснее Rust, Yandex сделала замеры

Спасибо большое за статью! В закладки!

Коронавирус: опасная иллюзия смертности

Респект за ошибку базового процента! Не знал про нее, но работает очень круто!

«Красная» корпоративная культура — главная проблема российского бизнеса (Часть 1)

Согласен на все 100%

Есть хорошая практика сравнивать производительность труда по отраслям/предприятиям.

Например: сравнить заводы «Северсталь» с другими металлургическими заводами мира, и выяснить как они отличаются. (Причем мерить не в $, а в тоннах производимой аналогичной продукции).

Или то же сельской хозяйство:
— сколько продукции собирается с гектара
— сколько нужно людей чтобы вырастить тысячу тонн условной пшеницы

Или возьмем средний хороший салон красоты в Москве и Париже.

Парикмахер в Москве постриг 8 человек за смену по 20$ (160$ вклад в ВВП),
Парикмахер в Париже подстриг 8 человек за смену по 50$ (400$ вклад в ВВП)

Их производительность труда одинаковая: 8 стрижек за смену. Но если учитывать вклад в ВВП в $, то вылезает разница в 2 раза.

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

P.S. я не утверждаю, что в РФ все идеально с производительностью, много где есть места для оптимизации. И измерять как раз надо производимую продукцию, в каждой конкретной отрасли, а не вклад в ВВП в $.

P.S.S. применительно к IT:
Возьмем Яндекс vs Google. Скорее всего сложность разработки поискового движка одинакова и для Яндекса и для Google. Но вот Яндекс «продает его» на 200 млн пользователей, а Google на 2 млрд. И скорее всего производительность программиста Google в 10 раз выше, чем программиста Яндекс. Хотя код по качеству и количеству они могут писать одинаковое количество.

И никак тот факт, что в Google доход в $ на программиста выше, чем в Яндексе, не означает, что Яндекс красная компания, а Google бирюзовая.

Вслед за Европой США запретили провозить на борту самолётов MacBook Pro

Я недавно по гарантии (спустя два года после покупки) бесплатно менял клавиатуру на Pro 17 года. В добавок бесплатно поменяли батарею.

Информация

В рейтинге
1,475-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность