• Как мы сэкономили 120 000 рублей в год на платном API Яндекс.Карт
    +1
    Вот интересно, когда жадность яндекса и гугла дойдет до такой степени, что дешевле будет разработать собственные карты с необходимым функционалом, нежели платить за API… (возвращаясь к статье про Google maps и приложение для визуализации зоны поражения ядерным взрывом)
  • Необходимый минимум по психологии для руководителя
    +3
    Особенно забавно то, какую проблему решают в сцене и которой кадр из «Selicon Valley» и как это ложится на тематику статьи.
  • Битва двух якодзун, или Cassandra vs HBase. Опыт команды Сбербанка
    +3
    Вы зануда :)
  • Ускользающий талант: Россия теряет лучших ИТ-специалистов
    +1
    Примерно это я имел в виду не вдаваясь в детали…
  • Ускользающий талант: Россия теряет лучших ИТ-специалистов
    +5
    Для технологического прорыва нужно не миллион IT специалистов, а с десяток гениев. Потому что бесконечное количество обезьян за бесконечное количество времени конечно напишут «Войну и мир», но лучше если это сделает один Толстой. А производить банковское ПО и прочие примитивные свисто-перделки может любой (сам этим занимаюсь :( ), технологическое отставание это не покроет.
  • Кого вы пытаетесь впечатлить своими дедлайнами?
    0

    — Команда должна организовываться самостоятельно.
    — Тогда какая же задача у Scrum мастера, если команда должна сама организовываться?
    — Как это какая? Создавать атмосферу конечно-же!
  • Кого вы пытаетесь впечатлить своими дедлайнами?
    +15
    Можно поделить компании на группы:
    1. Компании имеющие собственный продукт продающийся как есть. Тогда в случае невыполнения спринта мы просто пишем список новых фич и не включаем туда какую-то анонсированную которую не успели выпустить. А дальше пусть менеджмент разгребает, нечего было обещать и поднимать шумиху раньше времени (для этого кстати и нужна секретность и утечки информации, чтобы не делать официальных заявлений).
    2. Компания интегратор часто имеющая собственную систему которую она старается всячески везде интегрировать. Если клиент заплатил за интеграцию и не получил ее в указанные сроки то это плохо для интегратора, так делать нельзя.
    3. Тоже самое для производителя индивидуальных решений, компания клепает сайты-визитки. Если запланировано 3 сайта на спринт, и один не доделан то нужно выкручиваться, ведь обычно деньги получены заранее.
    4. Компания не IT направления имеющая собственное подразделение разработки для внутренних нужд, например банк. Банкиры создали бизнес — проект, проект ориентирован на незанятую нишу и нужно ее срочно занять и выйти на рынок с новым финансовым продуктом в установленные сроки. Если разработка эти сроки завалит то банк просто не успеет выйти с продуктом и вся разработка это просто — деньги в шредор.

    Системный анализ проблемы не подходит там где нужен комплексный. В данном случае проблема в планировании, нужна статья о том как планировать факапы. Ни разу не видел в IT чтобы кто-то сформировал график с трендом ожиданий и границами суммы погрешности оценок, для того чтобы отслеживать картину отклонений, собирать статистику и подбирать подходящий размер спринтов или иным способом регулировать работу команд.
  • Не боги горшки обжигают
    0
    Джун, это программист который может решить простую задачу «так чтоб работало», такого человека можно брать на работу, а дальше его должны научить старшие товарищи.

    Раз уж Вы практически весь мой пост процитировали)
  • Не боги горшки обжигают
    +1
    Ну вся программа обучения от школы до университета, по большей части требует от нас зубрежки. Преобладающее большинство отличников с которыми я имел честь общаться, просто зубрили информацию. Они даже спустя 15 лет ее помнят, но дальше уровня блеснуть знанием информации обычно ничего не доходит. Несправедливо требовать от новичка без опыта, умения применять свои знания на практике. Разум новичка в программировании просто не создаст ту ситуацию для которой потребуется тот или иной паттерн, ведь паттерны появились не сразу, их придумывали и полировали годами решая проблемы. Если взять нынешнего джуна с его багажом знаний и старого «морского волка» на том уровне когда он только начинал, я думаю, что первый еще фору сможет дать. Джун, это программист который может решить простую задачу «так чтоб работало», такого человека можно брать на работу, а дальше его должны научить старшие товарищи.
  • Не боги горшки обжигают
    +2
    Знание просто багаж, понимание это умение оперировать знаниями, сопоставлять их с опытом, находить пробелы в своем понимании и восполнять пробелы новыми знаниями. Просто знать мало для того чтобы применять. Человек без опыта может заучить все паттерны проектирования, но если задача выходит за рамки предоставленных примеров, или находится на их границе то без опыта трудно найти подходящее решение которое не породит кучу проблем в будущем.
    Знание — информация
    Понимание — совокупность опыта и знаний.
  • Не боги горшки обжигают
    0
    Поддержу. Сейчас джун в .net должен знать книгу Рихтера как библию, пусть не понимать, но знать должен.
  • Не боги горшки обжигают
    +1
    Во время второй мировой войны помимо сражений на фронтах происходила «гонка заводов», когда каждая из противоборствующих сторон старалась произвести как можно больше качественного боеспособного вооружения. Немецкий подход строился на мастерах, например в обработке листового алюминия, самолеты (например) собирались вручную и очень качественно, с другой стороны использовали подход когда в процессе производства преобладали не настолько квалифицированные рабочие. Конструкция танков, самолетов и т.д. позволяла их производить без выдающихся навыков. В результате каждая из сторон в отдельных отраслях произвела больше вооружения чем Германия. Проводя аналогию с программированием, нам дали хорошие инструменты, нам не надо часами выколачивать элемент фюзеляжа, достаточно пару раз бахнуть прессом. Что в этом плохого? «Стране» нужно больше софта, 60% программистов не нужно разбираться в тонкостях сопромата, свойствах металлов и так далее, ему просто нужно бахнуть прессом по куску железа. Со временем такой программист ошибется и положит не тот металл на пресс, и у него не получится, он начнет учиться и перейдет в следующие 40% где история будет повторяться до тех пор пока он не сделает свой пресс. А может быть он никогда не дойдет до этого уровня. Возвращаясь к зарплатам, это вранье, что через пол года курсов вас возьмут на работу за 100 в месяц, потолок 40. Другое дело если вы не только программист, а пришли в программирование как к прикладной дисциплине и являетесь специалистом в инженерии к примеру, тогда вы можете найти работодателя которому нужны именно вы и да, зарплата будет и 100 и 200 как договоритесь потому что нам платят до тех пор пока нас тяжело заменить.
  • Какую цену мы платим за использование async/await в языках JS / C# / Rust
    0
    Ну у меня претензии были к C# в JS я не разбираюсь.
  • Какую цену мы платим за использование async/await в языках JS / C# / Rust
    0
    Если я правильно понял, то вам нужно:
    1. Прочитать данные из кеша.
    2. В случае отсутствия данных выполнить расчет.
    3. В случае выполнения расчета, записать данные в кеш.
    4. Вернуть результат.
    Где проблема? Я чего-то не понимаю?
  • Какую цену мы платим за использование async/await в языках JS / C# / Rust
    0
    Конечно будет медленнее, конечно будет больше накладных расходов, асинхронность не для синхронных операций придумана. С точки зрения здравого смысла, зачем математическую операцию делать асинхронной? Она не падает в ожидание в процессе выполнения (разве что на уровне квантов). О чем статья, какой посыл?
  • Введение в REST API — RESTful веб-сервисы
    0
    Для «широких масс» PUT всегда ожидает положительного результата, даже если по факту он отрицательный, если вы считаете что в момент обновления данных может быть ошибка используйте POST.
  • Введение в REST API — RESTful веб-сервисы
    +1
    И все-же в заголовке лучше написать «Часть 1», так сказать «для широких масс»
  • Введение в REST API — RESTful веб-сервисы
    +3
    Тег не Java, а Http, Web или что-то в этом роде ну и таких статей выше крыши, слишком поверхностно.
  • 23 минуты. Оправдание тугодумов
    0
    Есть такая технология как «мозговой штурм», когда идеи высказываются без критики — просто чтобы были. И иногда именно таким образом находится оригинальное хорошее решение.


    Я об этом высказался, про высказывание идей без критики и дальнейший их анализ.
  • 23 минуты. Оправдание тугодумов
    +3
    Обычно при мозговом штурме каждая следующая идея идет с понижением коэффициента внимания относительно предыдущей и в результате вычленить адекватное решение тяжело, так как большинство сконцентрировано на первых решениях, для запоминания и анализа остальных просто не хватает ресурсов. Вспоминается сериал «корпорация», когда на таком брейншторме несли полную ахинею, пойди потом из этого бреда вычлени нормальное решение. Если такой подход возвести в абсолют то поиск адекватного решения в потоке бреда и есть мышление, просто предложенный подход выносит этот процесс за границы мозга одного, на всех остальных, еще и не эффективно выносит. Мозг обрабатывает мысль с точки зрения опыта и ассоциаций неосознанно учитывая множество факторов (у каждого человека разная степень компетенции и погружения). Если взять это за идею, что мы сначала генерируем идею командой, затем начинаем думать над каждым из пунктов. 5 человек генерируют по 10 идей, из них 2-3 будут уникальными для каждого и того получится примерно 20 идей. Каждую из 20 идей нужно проанализировать и обсудить (потому что компетенция у всех разная и уровень погружения разный, кто-то не знает того, что знаю остальные). В общем тупо задачи не решаются, тут думать надо.
  • Про одну Тётю
    0
    Ничего страшного в этом нет и плохого тоже в этом ничего нет. Конкуренция оздоравливает рынок и положительно сказывается на всех его участниках.
  • Про одну Тётю
    0
    Бизнес заработал, задачи решены, предприятия легли на сопровождение и долгосрочную поддержку, бизнесу хорошо. Сопровождать проекты можно и без «тёти», а то что в процессе потерялось несколько специалистов это издержки, «тётю» заменить тяжелее чем исполнителей в данном случае, а ее содержание бизнесу выгоднее. Придет время УПП перестанут пользоваться спросом, «тётя» либо приспособится либо потеряет работу, ведь ее уникальность в востребованных знаниях.
  • Про одну Тётю
    0
    Мужчины обычно руководствуются некими принципами, вызовут объяснят выскажут недовольство и накажут если это не действует. С данными женщинами все иначе, они действуют не прямо, а исподтишка. Надавят на непосредственного начальника, на совещании с руководством начнут жаловаться (при этом жалоб или претензий никогда не поступало), начнут настраивать коллег, распускать слухи. Как назвать иначе такого человека?
  • Про одну Тётю
    0
    А у меня на первом месте работы программистом (завод кстати). Была такая «тётя» — серый кардинал, начальник отдела аналитики. Не дай бог как-то ей поперек встанешь, спасти может только если будешь ключевым или уникальным специалистом, забавно то, что завод испытывал и испытывает трудности в плане квалифицированных кадров (зарплата маленькая для IT), но тёте это вообще не мешает. Это не инстинкт собственности это инстинкт «альфа-самки». В других направлениях я тоже сталкивался с такими руководителями, все они были женщинами, двуличными тварями и на работе и в жизни. Может быть имеет место профессиональная деформация и сложность для женщин вырасти до ключевой должности, осознание того, что каждый может подсидеть, и найти другую такую работу будет практически невозможно.
  • Микросервисы для начинающих
    0
    Для кого-то микросервис это атомарная часть архитектуры, для кого-то процесса бизнес-обработки. Кто-то делает распределенный монолит и называет это микросервисной архитектурой. Ну и да, все время в статьях, микросервисы == docker, хотя это просто среда развертывания и можно обойтись без него.
  • Рейтинг лучших CPU для игровых ПК в 2019 году
    0
    А вот мне интересно сравнение производительности процессоров при сжатии видео. У intel для этого есть Intel Quick Sync Video, а что есть у AMD и насколько расходятся показатели в этих задачах? Если кто-то натыкался на материал, прошу скинуть ссылку.
  • IGF 2019. Интернет разваливается на части?
    +4
    Все идет к тому, что границы государств будут очерчивать границы интернета и появится информационная таможня. Хочешь фильм скачать из германии, отправь заявку на рассмотрение, после анализа файла сможешь или не сможешь скачать. При этом таможня будет с обеих сторон досматривать и решать, дозволено ли тебе насладиться плодами кинематографа.
  • Проверка идеи будущего приложения. Претотип. Или как сэкономить много денег
    0
    Капитализм жесток
  • Как упаковать VueJS + NodeJS + MongoDB приложение в Docker
    +1
    Как упаковать VueJS + NodeJS + MongoDB приложение в Docker для среды разработки
  • Проверка идеи будущего приложения. Претотип. Или как сэкономить много денег
    +3
    Много историй о том, как делали одно, а получилось совсем другое, крутое и неожиданное. Надо делать, если кажется что идея того стоит и ею хочется заниматься, а иначе зачем это все? А если это изначально только бизнес, то не нужно делать ничего революционного есть более надежные вещи чем идея того, чего ни у кого нет.
  • Крутые лайфхаки для работы с WSL (Подсистема Windows для Linux )
    +1
    Чтобы постепенно стереть границу между Windows и Linux. Например при необходимости работы с специфическим софтом который есть только под одну ОС. Но выглядит пока не «user friendly»
  • Как я создал свой первый сайт и что из этого вышло
    +1
    Начинать стоит с идеи, здесь идеи нет. Если только не считать идеей эталон копипаста. Идея, реализация, подача, содержание — все копипаст.
  • Dell XPS 13 7390: очень компактный ноутбук для тех, кто часто работает вне офиса
    0
    А когда будет продаваться в России?
  • VM или Docker?
    0
    Как вариант, это балансировать нагрузку внутри KVM глуша и поднимая контейнеры. Допустим если мы размещаем на VM не кластер приложения, а отдельный пулл нод (есть не нагруженные сервисы например регистрация, а есть обработчики событий). Мы можем более тонко распределять нагрузку по нашим ограниченным ресурсам (не представляю правда когда это может понадобиться, но если случится «датапокалипсис» и всем не хватит железа… :D). При этом мы не трогаем конфигурацию наших виртуалок и всегда и везде используем один единственный стартовый снапшот для запуска.Тогда удастся выиграть пару минут для запуска дополнительных ресурсов. Идея в том, чтобы пережить непредусмотренный пик нагрузки.
  • VM или Docker?
    0
    Ну вот сценарий. У нас есть браузерная игра, игроки по всему миру. У игры есть getaway, балансировщик, штук 15 микросервисов, шардированная база данных (не важно сколько), ну и сервер очередей, пусть RabbitMQ. Надо при всплеске активности игроков в другой части земного шара, поднять кластер локационно ближе к ним. Оркестратор поверх докера позволит это сделать довольно быстро, особенно если уже есть подготовленные машины под контейнеры. При этом поднять столько нод, сколько нужно, глушить и поднимать их в зависимости от загрузки. Сколько времени по сравнению с контейнером потребуется одной виртуальной машине на запуск, сколько данных нужно перекинуть в нужный ЦОД для развертывания? Как только в одной части земли наступает ночь, в другой начинается день, и мы кидаем ресурсы в эту часть земли тратя деньги в тех ЦОД в которых нужно. Если этот сервер заточен под docker у него есть локальный репозиторий контейнеров, нам нужно только подтянуть наше приложение.
  • VM или Docker?
    +2
    Я бы с удовольствием прочитал статью о том, как выполнять «фишки» докера, на KVM. С докером все понятно, есть довольно простой язык описания контейнеров и неплохая документация. Но ничего подобного для KVM я не встречал (ну не сильно и искал). Если с помощью KVM можно без проблем собрать образ виртуалки, поместить в нее приложение и запустить, было бы неплохо узнать об этом подробнее. Не увидел в комментариях упоминания о использовании ресурсов, виртуалка вроде как потребляет больше ресурсов чем контейнер, и для одного единственного приложения (микросервиса) это такое себе решение. Другой вопрос если иметь для KVM такой-же репозиторий образов который есть у docker. В общем с нетерпением жду статью с таким сравнением.
  • Универсальный способ настройки внешнего вида WinForms приложения (на примере FAQ.Net)
    +1
    Тема раскрыта, но зачем?
  • Пишем блог на микросервисах – часть 1 «Общее описание»
    0
    Вроде как все сущности укладываются в рамки «документа», транзакционно зависимых CRUD операций на ум не приходит. Почему бы и не mongo, по сути на его месте может быть любая БД.
  • Книга «Head First. Kotlin»
    +2
    Вот все хорошо, но я работая на одной улице с издательством идеологически отказываюсь платить от 275р до 465р за доставку. Можно прямо в издательстве забрать (со скидкой само собой)?
  • Пишем блог на микросервисах – часть 2 «API Gateway»
    –1
    Микросервисы могут не сильно отличаться, но некоторые могут быть более нагруженны чем другие. Намного легче оптимизировать маленький микросервис, пусть и путем его переусложнения, чем то-же самое делать с более универсальным вариантом. Есть еще нюанс с горизонтальным масштабированием, когда не потребуется увеличивать количество экземпляров тяжелого сервиса часть функций которого тянется ненужным балластом. В принципе для блога, применение микросервисов это немного не целевое использование, но это же пример)