Недавно приобрел себе механику от Cooler Master Quick Fire с Cherry Red. В процессе выбора опирался на эргономику клавиатуры и компактность. Среди конкурентов этой клавиатуре рассматривал и игровые рейзеры и указанный в статье Leopold.
На мой сугубо личный взгляд и опыт (пользовался кстати и геймерскими razer blackwidow), Leopold не имеет никаких преимуществ перед купленной мною cooler master. Да, CM это больше игровая клавиатура, но при этом ее внешний вид не кричит «скорее запускай старкрафт и погнали катку!!!». Даже логотип CM находится на сзадней панели клавиатуры, и сразу даже не поймешь, что он значит.
Она идеально вписывается в офисное пространство, у нее точно такая же механика как и у всех, компактность и точно такая же эргономика как и у Leopold. Вот только она дешевле на 3 с лишним тысячи.
P.S. Ненавижу выбирать клавиатуры. 4 часа мучался с выбором и очень долго склонялся к китайским клавиатурам с aliexpress. Там выбор тоже далеко не маленький и разнообразие очень велико. Решил не рисковать)) Возможно зря.
Но есть нюансы. Зачастую, к счастью или нет, к нам клиент приходит с задачами запуска достаточно больших продуктов. И концепция этих продуктов включает в себя достаточно большой пласт задач.
Условно, нельзя создать ecom, в котором будет только перечень продуктов, которые поставляет клиент, без возможности оплаты через экваиринг и интеграцией с логистикой. Далее, туда же залетают критические фичи, без которых MVP не будет работоспособен - CEO продвижение, рассылка писем, процессы сквозной авторизации, управление товарами и прочее.
В совокупности, набор требуемых фичей просто, чтобы запуститься, становится весьма объемным. В основном, именно о таких системах и шла речь.
Грубо говоря, если использовать Вашу же метафору, самокат и рюказ не подойдут, если клиент торгует мебелью :)
Касаемо микросервисов, я не буду топить за подход реализации MVP через них. Довольно сложно на старте разделить как раз таки границы каждого. Если эти границы очертить возможно, то профит от них будет - легче заменить целый сервис на нормальный PIM, чем пытаться выкорчевать все процессы из монолита, которые на самописный PIM подписаны. Или же использовать готовые рекомендательные системы, чем развивать свою.
После выхода подобной системы на рынок, начинается процесс осмысления, выстраивания беклога и доработок уже нюансов. Микросервисы обрастают дополнительной логикой, усложняются и расширяются. Появляются побочные процессы, аналитика, укрупняются и добавляются интеграции. Эти процессы стоят дорого, кратно дороже чем реализация целого MVP (ведь нужно не просто сервис написать, но и подготовить внутренние регламенты и процессы бизнеса). Именно их на старте можно отрезать или упростить.
У всех разные грейды. Где-то middle это junior, где-то наоборот. Мы не готовы (пока) обучать с нуля, для этого нужна более сложная инфраструктура. В целом, мы ищем ребят, которым надо дать верный вектор развития и помочь получить опыт.
Я соглашусь, что они очень близки к позиции junior.
Стажер стажеру рознь. Но в целом, мы не требуем 100% изучения всех навыков в матрице - это зачастую нереально. Мы смотрим насколько человек активно прокачивает свои навыки, насколько он подходит команде, в которую попал. Множество субъективных параметров.
Если через 3 месяца мы понимаем, что стажер не прокачался до premiddle, но мы видим в нем перспективы - обычно даем оффер или (если все уж совсем плохо по хард скилам) продлеваем стажировку.
Не стоит бояться. Компании понимают, что стажировки это инвестиции в долгую и стажеры далеко не всегда обладают всеми нужными компетенциями. Для Вас это отличный способ пообщаться с профессионалами и понять, какие навыки вам стоит подтянуть. Если Вам повезет с интервьюером, то в фидбеке вы получите рекоммендации по изучению (книги/ссылки/статьи/технологии).
Изначально стажеры работают либо над внутренними проектами (у нас есть достаточно большой роадмап внутренней архитектуры), либо подключаются к тимлиду и он выдает задачи с реального проекта. Первое преобладает практически всегда. Собственно, нам нужно проверить кандидата - сколько реального времени готов выделять стажировке, как быстро изучает доку и т.п. После этой проверке (где-то через месяц, все индивидуально) подключаем к проектам.
Из задач на первом этапе - всегда попробовать фреймворк. Что-то исправить в существующем проекте, написать новый небольшой микросервис, иногда поинтегрировать что-то с чем-то. Из последних примеров: интеграция SSO с ldap, забекапировать карточки trello в Django и вывести это все в админку.
На реальных проектах, стажерам отдаются автотесты, исправление багов, работа со сторонними утилитами (sentry, elk, new relic), реализация тех улучшений (healthchecks, loggers и т.п.). Для стажеров это все в новинку и будет всегда интересно, а разработчики будут заниматься более срочными задачами. Все естественно под контролем тилмидов.
Судя по состоянию макларена, единственное, что ему помогает это Алонсо.
Так, несколько недель назад в Сингапуре команда Honda показала один из лучших своих результатов. И все это благодаря тому, что сами автомобили стали «умнее».
Я даже не знаю, как это назвать по другому, кроме как «невежество».
Клиент формирует нам Бизнес Требования, на основании которых уже наши аналитики продумывают объектную модель, формируют требования к интерфейсам и задание на разработку прототипов, а так же ТЗ.
После передаем требования проектировщикам на разработку интерфейсов и дизайн. В нашем случае, дизайн опущен, т.к. в ERP системах это не критично и мы в целом выдерживаем только определенные правила цветовой схемы и брендинга клиента.
ТЗ уже валидируется вместе с архитектором и тимлидами.
Обычно это занимает довольно много времени, проходит несколько этапов.
Как раз таки благодаря отсутствию больших коробок, мы можем прорабатывать объектную модель так, как считаем нужным. Мы не завязаны на кору, т.к. кор мы пишем сами. Как и говорил, это дольше и дороже, зато процессы выстроить проще и система строится именно под клиента.
Фин.система сейчас в процессе выстраивания. Вся идея сводится к тому, чтобы не подстраивать сервисы под финансовую модель, а агрегировать всю логику работы с финансами в рамках одного (пока что) сервиса. Пока на полную мощность эта интеграция не вышла, но ее архитектура позволит двигать ее куда будет нужно без аффекта на остальные сервисы.
У клиента достаточно узкоспециализированный бизнес. Хороших готовых коробок под его бизнес нет.
Вкручивать туда решения SAP — дорого. 1С — сложно интегрировать с остальными сервисами. Любая рассматриваемая коробка могла бы подойти, но имела кучу минусов. У нас возникали идеи использовать коллаборацию коробок (использовать готовые SRM и CRM системы), использовать их API и создавать сервисы вокруг. Но клиент решил, что он предпочтет переплатить за гибкий подход к его процессам и строить систему, которая не будет завязана на архитектуру коробки. На мой взгляд, это правильное решение в перспективе 3-4 лет.
Планы по развитию этой системы долгоиграющие. Планируется десятки интеграций в крупную экосистему головной компании. Подход сервисной архитектуры окажется проще и надежнее, когда это время придет.
Для меня лично, Вы сравниваете 2 совершенно разные системы и упускаете одно важное преимущество ELK.
ELK — это standalone система.
Наш клиент, к примеру, строго отказывается от всех облачных решений. Все сервера должны располагаться в закрытой корпоративной сети. Именно поэтому мы до сих пор не перешли на New Relic.
У меня лично проигрыватель появится только через пару месяцев и в нем я мало что смыслю, поэтому статья оч. полезна и отправилась в закладочки, дабы не потерять.
Совершенно не понимаю нападки на статью. Ну не любите винил — не любите дальше, слушайте flag в iTunes. Зачем вообще сравнивать качество музыки? Для меня винил = эстетика. Себе домой поставлю для атмосферы и декора.
У меня лично со сбербанком связаны только отрицательные эмоции.
Я до сих пор не закрыл 2 счета по картам по той простой причине, что закрываются они при личном присутсвии в отделении, в котором были открыты (а это в другом конце Москвы).
Сейчас компания, в которой я работаю, «попросила» меня открыть счет в сбербанке и оформить там зарплатную карту. Теперь каждый месяц мне приходится звонить в сбербанк и просить их разблокировать мою карту. А все по той простой причине, что я делаю перевод с карты на карту через Тинькофф банк (там есть замечательная услуга по переводу с карты на карту любого банка без комиссии). Уважаемый (сарказм) сбербанк видя транзакцию со стороннего сайта, преспокойно проводит ее и блокирует карту за сомнительные операции. Г — логика.
На мой сугубо личный взгляд и опыт (пользовался кстати и геймерскими razer blackwidow), Leopold не имеет никаких преимуществ перед купленной мною cooler master. Да, CM это больше игровая клавиатура, но при этом ее внешний вид не кричит «скорее запускай старкрафт и погнали катку!!!». Даже логотип CM находится на сзадней панели клавиатуры, и сразу даже не поймешь, что он значит.
Она идеально вписывается в офисное пространство, у нее точно такая же механика как и у всех, компактность и точно такая же эргономика как и у Leopold. Вот только она дешевле на 3 с лишним тысячи.
P.S. Ненавижу выбирать клавиатуры. 4 часа мучался с выбором и очень долго склонялся к китайским клавиатурам с aliexpress. Там выбор тоже далеко не маленький и разнообразие очень велико. Решил не рисковать)) Возможно зря.
Со всем согласен :)
Но есть нюансы. Зачастую, к счастью или нет, к нам клиент приходит с задачами запуска достаточно больших продуктов. И концепция этих продуктов включает в себя достаточно большой пласт задач.
Условно, нельзя создать ecom, в котором будет только перечень продуктов, которые поставляет клиент, без возможности оплаты через экваиринг и интеграцией с логистикой.
Далее, туда же залетают критические фичи, без которых MVP не будет работоспособен - CEO продвижение, рассылка писем, процессы сквозной авторизации, управление товарами и прочее.
В совокупности, набор требуемых фичей просто, чтобы запуститься, становится весьма объемным.
В основном, именно о таких системах и шла речь.
Грубо говоря, если использовать Вашу же метафору, самокат и рюказ не подойдут, если клиент торгует мебелью :)
Касаемо микросервисов, я не буду топить за подход реализации MVP через них. Довольно сложно на старте разделить как раз таки границы каждого. Если эти границы очертить возможно, то профит от них будет - легче заменить целый сервис на нормальный PIM, чем пытаться выкорчевать все процессы из монолита, которые на самописный PIM подписаны. Или же использовать готовые рекомендательные системы, чем развивать свою.
После выхода подобной системы на рынок, начинается процесс осмысления, выстраивания беклога и доработок уже нюансов. Микросервисы обрастают дополнительной логикой, усложняются и расширяются. Появляются побочные процессы, аналитика, укрупняются и добавляются интеграции. Эти процессы стоят дорого, кратно дороже чем реализация целого MVP (ведь нужно не просто сервис написать, но и подготовить внутренние регламенты и процессы бизнеса). Именно их на старте можно отрезать или упростить.
У всех разные грейды. Где-то middle это junior, где-то наоборот. Мы не готовы (пока) обучать с нуля, для этого нужна более сложная инфраструктура. В целом, мы ищем ребят, которым надо дать верный вектор развития и помочь получить опыт.
Я соглашусь, что они очень близки к позиции junior.
Стажер стажеру рознь. Но в целом, мы не требуем 100% изучения всех навыков в матрице - это зачастую нереально. Мы смотрим насколько человек активно прокачивает свои навыки, насколько он подходит команде, в которую попал. Множество субъективных параметров.
Если через 3 месяца мы понимаем, что стажер не прокачался до premiddle, но мы видим в нем перспективы - обычно даем оффер или (если все уж совсем плохо по хард скилам) продлеваем стажировку.
Не стоит бояться. Компании понимают, что стажировки это инвестиции в долгую и стажеры далеко не всегда обладают всеми нужными компетенциями. Для Вас это отличный способ пообщаться с профессионалами и понять, какие навыки вам стоит подтянуть. Если Вам повезет с интервьюером, то в фидбеке вы получите рекоммендации по изучению (книги/ссылки/статьи/технологии).
Изначально стажеры работают либо над внутренними проектами (у нас есть достаточно большой роадмап внутренней архитектуры), либо подключаются к тимлиду и он выдает задачи с реального проекта. Первое преобладает практически всегда. Собственно, нам нужно проверить кандидата - сколько реального времени готов выделять стажировке, как быстро изучает доку и т.п. После этой проверке (где-то через месяц, все индивидуально) подключаем к проектам.
Из задач на первом этапе - всегда попробовать фреймворк. Что-то исправить в существующем проекте, написать новый небольшой микросервис, иногда поинтегрировать что-то с чем-то. Из последних примеров: интеграция SSO с ldap, забекапировать карточки trello в Django и вывести это все в админку.
На реальных проектах, стажерам отдаются автотесты, исправление багов, работа со сторонними утилитами (sentry, elk, new relic), реализация тех улучшений (healthchecks, loggers и т.п.). Для стажеров это все в новинку и будет всегда интересно, а разработчики будут заниматься более срочными задачами. Все естественно под контролем тилмидов.
Задачи найти не так сложно на самом деле.
Я даже не знаю, как это назвать по другому, кроме как «невежество».
После передаем требования проектировщикам на разработку интерфейсов и дизайн. В нашем случае, дизайн опущен, т.к. в ERP системах это не критично и мы в целом выдерживаем только определенные правила цветовой схемы и брендинга клиента.
ТЗ уже валидируется вместе с архитектором и тимлидами.
Обычно это занимает довольно много времени, проходит несколько этапов.
Как раз таки благодаря отсутствию больших коробок, мы можем прорабатывать объектную модель так, как считаем нужным. Мы не завязаны на кору, т.к. кор мы пишем сами. Как и говорил, это дольше и дороже, зато процессы выстроить проще и система строится именно под клиента.
Фин.система сейчас в процессе выстраивания. Вся идея сводится к тому, чтобы не подстраивать сервисы под финансовую модель, а агрегировать всю логику работы с финансами в рамках одного (пока что) сервиса. Пока на полную мощность эта интеграция не вышла, но ее архитектура позволит двигать ее куда будет нужно без аффекта на остальные сервисы.
Вкручивать туда решения SAP — дорого. 1С — сложно интегрировать с остальными сервисами. Любая рассматриваемая коробка могла бы подойти, но имела кучу минусов. У нас возникали идеи использовать коллаборацию коробок (использовать готовые SRM и CRM системы), использовать их API и создавать сервисы вокруг. Но клиент решил, что он предпочтет переплатить за гибкий подход к его процессам и строить систему, которая не будет завязана на архитектуру коробки. На мой взгляд, это правильное решение в перспективе 3-4 лет.
Планы по развитию этой системы долгоиграющие. Планируется десятки интеграций в крупную экосистему головной компании. Подход сервисной архитектуры окажется проще и надежнее, когда это время придет.
ELK — это standalone система.
Наш клиент, к примеру, строго отказывается от всех облачных решений. Все сервера должны располагаться в закрытой корпоративной сети. Именно поэтому мы до сих пор не перешли на New Relic.
Тоже считаю отличной книгой. Открыла мне многое.
Совершенно не понимаю нападки на статью. Ну не любите винил — не любите дальше, слушайте flag в iTunes. Зачем вообще сравнивать качество музыки? Для меня винил = эстетика. Себе домой поставлю для атмосферы и декора.
Я до сих пор не закрыл 2 счета по картам по той простой причине, что закрываются они при личном присутсвии в отделении, в котором были открыты (а это в другом конце Москвы).
Сейчас компания, в которой я работаю, «попросила» меня открыть счет в сбербанке и оформить там зарплатную карту. Теперь каждый месяц мне приходится звонить в сбербанк и просить их разблокировать мою карту. А все по той простой причине, что я делаю перевод с карты на карту через Тинькофф банк (там есть замечательная услуга по переводу с карты на карту любого банка без комиссии). Уважаемый (сарказм) сбербанк видя транзакцию со стороннего сайта, преспокойно проводит ее и блокирует карту за сомнительные операции. Г — логика.