Я полагаю, вы знакомы с инструментами разработчика браузера Chrome. Мы можем использовать его для просмотра сетевых запросов, анализа производительности веб-страницы и отладки последних функций JavaScript.
В дополнение к этому, он также предоставляет множество мощных, но необычных функций, которые могут значительно повысить эффективность нашей разработки!
Утро. Не вставая с кровати, проверяю почту и мессенджеры в телефоне – вдруг на нашу планету свалился метеорит, а я все проспал? Собираюсь на работу, попутно узнавая в приложении погоду, просматривая в интернете новую рубашку и заказывая такси. На работе без телефона не хожу даже в туалет – вдруг срочный звонок? В кафе на обеде расплачиваюсь тоже, телефоном. Вечером вместо оперы смартфон транслирует подкаст. На ужин – пицца, заказанная из приложения.
Телефону удобно делегировать бытовые задачи. Все очень просто и интуитивно понятно. Это помогает экономить время, силы, энергию, деньги. Повышает комфорт и уровень жизни.
Сегодня решение бытовых проблем с помощью телефона – обыденность. Но каждая новая функция, которую осваивал смартфон, всегда имела WOW-эффект.
Все персонажи и события являются вымышленными. Любое совпадение с реально живущими или когда-либо жившими людьми случайно.
- А почему вы используете в расчете КП наценку и маржу?
- Директор по операциям так сказал делать.
- Хм, а этот показатель что означает?
- Это инфляция на второй год, заложенная в стоимость продукта на следующий год.
- А к моменту подписания актов и сдаче проектов в компании есть отчет по фактическим трудозатратам и рентабельности проекта?
- Нет, а зачем?
Если упустить критику в адрес терминологического обоснования наценки и маржи для it-проектов, то следует углубиться в изучение проекта.
Для разработки новых проектов, обладающих большой зоной неизвестности и следовательно риска, а также понимая использование аджайл подхода к управлению, кажется малопонятным не только сам подход к прогнозированию трудозатрат, но и определение емкости будущего рынка и как следствие будущей выручки. Поэтому на начальном этапе чаще всего планируется требуемое время на разработку нового продукта и прогнозная стоимость, по которой этот продукт можно было бы продать текущим заказчикам.
Для тех проектов, работа по которым ведется в рамках регламента и с соблюдением рутин, кажется более реалистичным предварительная оценка и понимание стоимости проекта. Стоимость проекта для заказчика складывается из времени сотрудников, участвующих в реализации проекта, которое компания перепродает заказчику с некоторой наценкой, заложенных рисков (оцениваемых по выстроенным критериям исходя из логики и/или предыдущего опыта) и затрат, которые it-компания планирует переложить на заказчика. К последним можно отнести премиальную часть, которую после завершения сделки получит команда, налоги к уплате и т.д.
Сегодня я хочу рассказать о новом применении блокчейна и криптовалют - набирающем популярность движении play-to-earn или играй-чтобы-зарабатывать.
Добрый день Хабрчане!
В этом посте я хочу поделиться с вами своим скромным опытом в написании софта для удаленного управления БЗК Никон Z6. Точнее правильнее будет сказать не «написании», а скорее «допиливании», однако более подробно об этом я напишу ниже. Ну а сначала я расскажу немного о себе и о том, что именно - натолкнуло меня на такую, на первый взгляд, бредовую идею.
Итак, меня зовут Вадим, мне сорок с хвостиком, и я то, что называется Jack of all trades. Однако в первую очередь – я коммерческий фотограф, специализирующийся на технической, индустриальной и предметной фотографии. Чуть больше двадцати лет назад, когда вопрос определения специальности и выбора соответствующего ВУЗа, встал, так сказать, ребром – я понял что сфера IT и написание кода руками – явно не удовлетворяют мои творческие амбиции. Поэтому я решил остановить свой выбор на творческой профессии, и, несмотря на протесты родителей, поступил в академию искусств на факультет фотографии. В ретроспективе я не берусь утверждать, что мой выбор профессии – был наиболее удачным с финансовой точки зрения. Однако - я изо дня в день занимаюсь тем, что приносит мне огромное удовольствие и чувство глубокого морального удовлетворения. На сегодняшний день я признанный и востребованный специалист в вопросах сложных технических съемок и интеграции различного рода фотооборудования в различных отраслях. Ах да, вдобавок к этому - я жуткий зануда, и технократ. Наверное, именно эти черты моего характера, и привели меня к мысли о написании своей софтинки…
Для работы бывает полезно иметь несколько копий одной реальной базы для экспериментов, фикстур или просто тестовых приложений. База растет и время копирования через разворачивание дампа или с помощью шаблона также возрастает до утомительных величин. Для решения этого кейса уже описаны варианты использования файловой системы с поддержкой CoW - Btrfs. В интернете находил такие инструкции, они сводятся к тому, что делается снепшот всего сервера. И для работы второго "скопированного" нужно перегенерировать pid и сменить порт для предотвращения конфликтов. Этот способ довольно универсальный относительно конфигурации баз на сервере, но кажется имеет ограничение для неопределенного кол-ва параллельных снепшотов серверов.
В этой статье предлагаю свой вариант реализации снепшотов на одном экземпляре сервера postgres и одной базы, на произвольное кол-во копий.
Инструкция linux only, про поддержку CoW файловых систем на Windows не в курсе.
print(1 + 2)
print, (, 1, +, 2 и )
В своей предыдущей статье я уже упоминал, что создаю своё микрооблако. Точнее, ну как своё, это будет облако как продукт, а не как услуга. Поэтому оно такое же моё, как и ваше. Как и всего мира. То есть каждый сможет его развернуть на своё железо, будь то датацентр или пара-тройка виртуальных машин и пользоваться им в своё удовольствие, запуская на нем свои потрясающие проекты. Можно даже найти какой-то готовый проект, который лежит где-нибудь на гитхабе и давно просится на старт, только автору исходного кода запускать его было негде, потому что хранение исходников у нас бесплатное, а вот поддержка работы своего сервиса к дешевому сегменту экономики на мой взгляд не относится. А я такой запустил облако, вкинул туда чужой проект и помог миру увидеть то, что так и могло остаться в глубинах гитхаба. Но это фантазии, до реализации которых еще далеко, но путешествие в тысячу миль начинается с первого шага, главное не прекращать перебирать ногами. Поэтому мы продолжаем...
Так вот в прошлом посте в рамках проекта kubos мы остановились на том, что объединили все машинки нашего будущего облака в общую виртуальную сеть. Теперь пора сделать так, чтобы машинки видели друг друга не только по IP-адресам, но и по именам. Для этого нужно запустить и настроить DNS сервер, чем мы сейчас и займемся. Для этого я отвел в гитлабе отдельную ветку, где и будет приведен полный код ansible и не только скриптов, о которых пойдет речь ниже.
Двое молодых математиков ошеломили коллег, представив полное доказательство гипотезы Кана-Калаи — обобщающее утверждение о том, как возникает структура в случайных множествах и графах.
Когда математики Джефф Кан и Гиль Калаи в 2006 году впервые выдвинули свою гипотезу о «пороге ожидания», они сами в нее не поверили. Их тезис – широкое утверждение о природе математических объектов, именуемых «случайными графами» — казался слишком категоричным, слишком всеобъемлющим, слишком смелым, чтобы претендовать на истинность. Казалось, что он скорее выдает желаемое за действительное, чем отражает математическую истину. Даже с такими оговорками, никто не смог опровергнуть эту гипотезу, и она быстро стала одной из важнейших нерешенных задач в своей области.
Теперь, более 15 лет спустя, двое молодых математиков из Стэнфордского университета сделали то, что, по мнению Кана и Калаи, граничит с невозможным. В на удивление кратком препринте, выложенном в онлайне всего несколько недель назад, Джинён Пак и Гью Туан Фам дали полное доказательство этой гипотезы.
«Оно получилось поразительно простым и изобретательным», — сказал Калаи, — «Завораживающим. Чудесным».
Не претендую на открытие Америки в этой публикации, т.к. она является компиляцией различных комментариев и статей, в т.ч. на Habr. Не судите строго, надеюсь на помощь в развитии этого направления. Делал эту инструкцию для себя и специально с нуля, чтобы каждый новичок смог повторить те же действия.
Промышленные решения, основанные на машинном обучении — это гораздо больше, чем просто модель. Три ключевые концепции, охватывающие управление версиями, тестирование и конвейеры, являются основой для операций машинного обучения (MLOps), которые помогают группам по анализу данных быстрее и увереннее выпускать модели.
Малоподвижный образ жизни, повышенное давление, лишний вес, стресс, некачественный сон, курение, переработки — все это может привести к инсульту. И не надо думать, что инсульт случается только с пожилыми. Треть больных — это люди трудоспособного возраста. При этом лишь 10–20% (по разным данным) пациентов после болезни возвращаются к труду.
Посмотрим на данные официальной российской статистики: в стране ежегодно происходит более 400 тысяч случаев инсульта, причем лишь 8–10% из них оказываются относительно легкими и заканчиваются восстановлением нарушенных функций в первые три недели заболевания.
Голосовые ассистенты незаметно вошли в нашу жизнь с появлением умной колонки Алисы. Многие известные финтех компании внедряют голосовых помощников в свои продукты, так что теперь при использовании мобильных приложений пользователь вынужден привыкать к мультимодальным интерфейсам. Но несмотря на их возрастающую популярность голосовые помощники требуют серьёзных доработок.
У меня как UX-адепта возникает череда вопросов, требующих изучения. Насколько просто использовать голосового помощника в мультимодальном интерфейсе? По какому пути проходит типичный пользователь, используя приложение с голосовым ассистентом? Насколько ему комфортно и просто общаться с голосовым ассистентом, решая свою задачу? Чтобы найти ответы на эти вопросы, я провела модерируемое юзабилити тестирование мобильного приложения Салют.
Всем привет! Это моя первая статья на Хабр. Меня зовут Артем Сосульников и я директор по разработке ПО в Luxoft. В IT больше 15 лет: начинал как Java разработчик, прошел долгий путь от тим лида и руководителя проектов до директора по разработке ПО с сотней людей в подчинении. В связи с последними событиями в ближайшее время собираюсь с семьей переезжать на остров Пенанг в Малайзию и присоединиться к Люксофт.Малайзия. Там продолжу развитие своих проектов в квантовых хэдж фондах, куда мы теперь нанимаем людей в Сербии, Мексике и Малайзии. Буду писать статьи про жизнь в Малайзии и про работу в Люксофт.
Можно ли расти профессионально, не меняя работу. Думаю, я не одна, кто задавался этим вопросом.
