User
Платить работникам рыночную зп, или выше рынка? Раздувать штат "сдельщиков", или выжимать максимум производительности из каждого сотрудника? Что делать, если сотрудники работают "с прохладцей"? Ищем ответы у классика менеджмента Ф.У.Тейлора.
Эта заметка — попытка вкусно рассказать о книге Тейлора 1911 года, вызвать у вас желание её прочесть, и не наспойлерить. Из заметки вы узнаете, что сказал Ленин по поводу этой книги, а также мнение Питера Друкера: кто круче — Маркс, или Тейлор.
Пожалуй, нет ни одной крупной IT компании, которая бы не страдала от огромного и неповоротливого legacy, состоящего из тесно переплетенных между собой решений. Каждое решение связано с несколькими другими, и добавление одной новой, на первый взгляд незначительной, фичи требует изменения чего-то в каждом. Отдельные решения устарели настолько, что они в принципе не могут дать новый нужный функционал, и их нужно переписать полностью или заменить современным решением - и его, соответственно, также встроить во всю архитектуру. Это делает новые запуски сложными и долгими.
Иногда размер технического долга оказывается настолько большим, что для его устранения запускаются отдельные проекты, рассчитанные на месяцы и годы - а это сопоставимо с 5-10 time-to-market новых решений. Соответственно, все новые запуски откладываются до тех пор, пока авгиевы конюшни не будут расчищены, покрашены и перестроены. Отдельное зрелище - СТО, который убеждает СЕО и добрую половину правления, а также акционеров, потратить несколько тысяч человекочасов драгоценных разработчиков на то, что по завершении не поможет бизнесу моментально, а только ускорит на неизвестное время получение выгод от новых продуктов в будущем. Правда, после того, как запуск каждого из этих продуктов будет отложен на несколько месяцев.
В моменте, руководителям компании предстоит пройти через множество трудных обсуждений, оценок сроков и приоритизаций. Стратегически же, пренебрежением техническим долгом и отсутствие видение в создании IT архитектуры может вылиться в то, что более мелкий и гибкий конкурент обойдет компанию на рынке, так как сможет быстрей выйти на рынок с перспективным продуктом.
Бессерверные сервисы облачных вычислений появились в 2014 году с AWS Lambda, которая позволяла запускать код без выделения серверов или управления ими. AWS Lambda — пример функции как услуги (FaaS), где результат обработки событий не зависит от состояния памяти сервера и содержимого локальной файловой системы. Такие эластичные вычисления позволяли быстро наращивать и высвобождать ресурсы процессоров, памяти и средств хранения без необходимости что-то планировать и предпринимать меры для обработки пиковых нагрузок.
За AWS Lambda быстро последовали решения от Microsoft Azure и Google Cloud. Позже облачные провайдеры начали предлагать и другие услуги в бессерверной форме. Это последний, новый взгляд на облачные сервисы, и на практике бессерверные архитектуры за счет возможностей масштабирования часто обходятся в разы дешевле, чем постоянные серверы, предназначенные для выполнения тех же нагрузок.
Сейчас бессерверных решений все больше, в том числе пару лет назад появились и первые проекты в России. На Хабре о бессерверных вычислениях есть раздел, но куда менее популярный, чем он того заслуживает. Попытаемся это исправить.
Итак, Serverless. Крупным планом.
Ах, это соблазнительное желание «запилить свое приложение». Все мы с ним знакомы. Как ему не поддаться? Но столкнувшись с вопросами «как» и «где» разместить свой код, многие бросают эту затею. А это еще не было вопроса «Зачем».
В этой статье я хочу поделиться опытом, рассказать, как развернуть свое первое SaaS-приложение. Также разберем, как его развить в будущем. Это материал для тех, кто давно собирался, но не знает, как.
Это экспериментальная статья про Research&Development, технологии для создания новой ценности для клиента — потому не будет ни слова про техническую часть. Будет немного про историю и культуру DevOps , а также про процессы, культурные особенности, взаимодействие внутри инженерных команд и, конечно, особенности появления R&D внутри них.
Сразу скажу, что это немного идеалистичная картина для нашего российского IT. У нас еще мало компаний, которые дейсвительно используют R&D в качестве основного зарабатывающего бизнес-юнита. В основном лишь частично внедряются практики, взаимодействие и культуру DevOps. Но это не значит, что туда не надо идти. Если у вас это вызовет отторжение: «Такого не бывает, это не работает», то предлагаю превратить это в вопрос: «Такого не бывает? Это не работает?»
Меня зовут Александр Титов, первые DevOps-практики я начал использовать еще до того, как появилось само слово DevOps. Сейчас я управляющий партнер в компании Экспресс 42, которая помогает ставить DevOps в компаниях.
Привет, я Ред из Scalable, занимаюсь в компании развитием продуктов. В последнее время криптоиндустрию, впрочем как и остальные отрасли, потрясывает. Поэтому на правах разработчика трейдинговой white-label платформы решил поделиться с общественностью, как устроена криптоиндустрия, какие риски в ней существуют и как в нее можно “зайти” помимо покупки криптовалюты. Никакой рекламы криптоскама и призывов поторговать на более лучшей бирже – только матчасть.
Так как статья была написана до известных политических событий, то поведение бирж, регуляторов и других участников индустрии в кризисах здесь не отражено. Расскажу, как это работает вне политики.
В предыдущей статье я вкратце упомянул, что Knime умеет работать с базами данных, в том числе с NoSQL базой MongoDB. На мой взгляд, MongoDB является довольно простым и эффективным решением для хранения информации, представленной в виде коллекций документов, состоящих из различных наборов полей и, по сути, являющихся обычными JSON файлами. Мне показалась интересным попробовать связку Knime - MongoDB в действии. Именно этой связке и посвящена данная статья.
Хотели когда-нибудь примерить на себя костюмчик успешного архитектора из мира больших бизнесов? Ну тех, кто зарабатывает на лекциях и подкастах больше, чем на основной работе. Рецепт то не особенно сложный: пара успешных проектов и кул стори в интернетах. Впахивай и впаривай! Иногда в комплекте к костюму идут одноцветные тапочки…
Если Вы подумали, что стоматологи нашли способ отправлять зуб на карантин, то спешу Вас огорчить, эта статья немного о другом. А именно о изоляции зубов с помощью системы коффердам.
Коффердам - это немецкое слово, которое можно дословно перевести как: "резиновая преграда", что очень ярко отражает весь смысл.
В конце февраля жизнь огромного количества людей кардинально изменилась. Одновременно с этим у многих внезапно проснулось жгучее желание вот прям сейчас немедленно посетить одну из соседних стран и полюбоваться ее природными красотами.
Я не был исключением. Мой выбор пал на горную Киргизию. За последние два месяца я увидел очень мало отзывов и рассказов от айтишников, которые уехали в Бишкек, поэтому я решил написать свой. Если вам интересно, как живется в Бишкеке, как тут обстоят дела с интернетом и работой и как киргизы относятся к русским, то добро пожаловать под кат!
Решил на досуге выбрать компании на фондовой бирже, которые бы мне подходили. Заодно получилось небольшое исследование на тему спекулятивных акций. В этой статье я отсортировал акции индекса IMOEX с точки зрения привлекательности для спекулянта, а также заметил возможную причину сильного дневного роста некоторых из них. (Автор не претендует на исчерпывающее объяснение — это просто информация для размышления)
Иногда системы контроля версий напоминают групповые чаты: вроде бы все тут собрались по какому-то поводу и пишут о чём-то одном, но что именно пишут ― разобраться порой просто невозможно. Как и в чате, где на одно грамотное и полное сообщение наберётся сотня «гыгы, лол» и «))))))», в Git-коммитах на несколько внятных описаний приходится втрое больше чего-то такого:
c63b59c ЛОГИКА РАБОТЫ File[] filesList; (ВНИМАНИЕ!)
3775079 Правки самые последние NEW
71acc53 Правка последняя
Особенно это становится заметно во времена крупных доработок. Когда у разработчика много задач и горящих дедлайнов, есть соблазн плюнуть на написание нормальных комментариев к коммитам (commit messages) и применить золотое антиправило экономии времени «Разберусь потом». Но когда наступает это «потом», комментарии типа «03.03 – 04.03» или «последняя правка» не дают ничего, кроме чувства досады на себя в прошлом.
В этой статье мы решили напомнить про правила хорошего тона при написании комментариев к коммитам, чтобы позаботиться о себе и своих коллегах.
Каждый раз, когда мы смотрим на какую-либо огромную компанию, будь это McDonald`s, Apple или Starbucks мы думаем: “У них хороший продукт, много клиентов, у них все хорошо, куплю я эту компанию, она будет расти!”
Но мы не знаем, какой этот бизнес изнутри. А что, если он тратит практически все средства чтобы сделать продукт, либо вообще, имеет отрицательный денежный поток? А может ей не хватает денег чтобы развиваться? Может из-за смены руководства у компании появились проблемы, и она стала неэффективной?
А что, если она когда-то набрала огромное количество долгов и сейчас сводит концы с концами, чтобы выплатить их?
Привет от Technology Enthusiast! Сегодня речь пойдет о сервисах интеграции данных, их функциональных возможностях и ограничениях. Рассмотрение будем вести на примере сервиса myBI Connect, опираясь на который я реализовал с десяток аналитических проектов за последние несколько лет.
Отмечу, что с конца февраля ребята сделали значительные шаги в сторону развития отказоустойчивости и масштабируемости своего решения. Заглядывайте под кат, если стоите перед выбором коннектора или хотите выжимать максимум из доступного:
• Требования и ожидаемые результаты
• Функциональные возможности
• Сценарии использования и бизнес-ценность
• Планы развития, продвинутое моделирование и BI
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
В этой статье я собираюсь продемонстрировать особенности планов исполнения запросов при обращении к секционированным таблицам. Обратите внимание, что существует большая разница между секционированными таблицами (которые стали доступны только с SQL Server 2005) и секционированными представлениями (которые были доступных ещё в SQL Server 2000, и по-прежнему доступны в SQL Server 2005 и последующих версиях). Особенности планов запросов к секционированным представлениям я продемонстрирую в другой статье.
Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:
• состояли из 3-10 JOIN-ов по коррелирующим запросам;
• уielded от 10 до 1,000,000 строк;
• должны были выполняться в течение времени, определенного UX-ом;
• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;
• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.
Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.
У нас не нашлось «заклинания», которое решило бы все проблемы с производительностью SQL. Тем не менее, я упомяну здесь несколько дельных предложений, которые помогли нам и, надеюсь, смогут помочь читателю. Разумеется, это не какие-то сакральные знания. Но когда мы начинали оптимизацию, я был бы рад их прочитать или услышать.
Добрый день Хабр. Сегодня, мы с вами окунемся в «О дивный мир» форензики. В данной статье Мы решили собрать программы, которые помогут Вам в проведении расследований и, что немаловажно, будут при этом бесплатными.
DISCLAIMER: Данная статья написана в ознакомительных целях и не является руководством к неправомерным действиям или обучающим материалом для сокрытия правонарушений.
