Дима Пацура (https://twitter.com/ovrweb) рассказал в эфире "Цинкового прода" про аналитическую платформу cube.js
https://youtube.com/watch?v=YcpYmPOTq98
https://youtube.com/watch?v=YcpYmPOTq98
Появились записи докладов с gopherCon Russia. Enjoy!
https://www.youtube.com/channel/UCq-OB01F8YnS-FJpeJRCvMQ/videos
https://www.youtube.com/channel/UCq-OB01F8YnS-FJpeJRCvMQ/videos
Рубрика ответов на нашумевшие твиты продолжается.
А вы стали бы убирать говно за бомжами вместо программирования, если бы вам платили в два раза больше?
Я - точно нет. Поэтому зп - точно не единственный фактор, хотя и экстремально важный.
https://mobile.twitter.com/AntonOkolelov/status/1389782725595435014
А вы стали бы убирать говно за бомжами вместо программирования, если бы вам платили в два раза больше?
Я - точно нет. Поэтому зп - точно не единственный фактор, хотя и экстремально важный.
https://mobile.twitter.com/AntonOkolelov/status/1389782725595435014
Twitter
Anton Okolelov
Хороший, эффективный наброс. Деньги, конечно, очень важны. Однако, не только они. Скажи, @fillpackart, ты стал бы вместо программирования убирать говно за бомжами, если бы тебе платили x2? :) Важны деньги, задачи, уважение, технологии, процессы и чтоб начальник…
Статья о том, что в Go не нужен крутой garbage collector как в Java, потому что у таких языков как Go гораздо меньше аллокаций в куче.
Статья интересная. От себя замечу, что некорректно вообще-то сравнивать Go и Java. И тем более Rust.
Go - для маленьких эффективных микросервисов, и упор на грамотное выделение памяти (а не на хитрожопый GC) оправдан.
Java - для ООП-монстров, набитых бизнес-логикой, возможно там нужен именно что крутой GC, и это норма.
Rust - для лютого байтоёбства, где нужно экономить каждый бит данных и такт процессора, даже ценой переусложнения кода. Для написания БД, например. В Расте вообще нет GC, точнее, где именно чистить память известно уже на этапе компиляции, в рантайме ничего колдовать не надо.
Все три подхода оправданы для своих целей.
Алсо мы тут поспорили в Фейсбуке, нормально ли на Java писать базы данных. Все знают, что есть куча примеров, те же Kafka и Elastic, написанные на этом языке. Однако честно скажу. Мне все же кажется, что при разработке Кафки наверняка пришлось заниматься лютейшим байтоёбством, выжимать максимум производительности и минимизировать память.
А ебать байты на java всё же в 100 раз сложнее, чем на системных языках, где это всё из коробки.
Поэтому если б я сейчас писал кафку, я бы точно выбрал какой-нибудь Раст.
Статья интересная. От себя замечу, что некорректно вообще-то сравнивать Go и Java. И тем более Rust.
Go - для маленьких эффективных микросервисов, и упор на грамотное выделение памяти (а не на хитрожопый GC) оправдан.
Java - для ООП-монстров, набитых бизнес-логикой, возможно там нужен именно что крутой GC, и это норма.
Rust - для лютого байтоёбства, где нужно экономить каждый бит данных и такт процессора, даже ценой переусложнения кода. Для написания БД, например. В Расте вообще нет GC, точнее, где именно чистить память известно уже на этапе компиляции, в рантайме ничего колдовать не надо.
Все три подхода оправданы для своих целей.
Алсо мы тут поспорили в Фейсбуке, нормально ли на Java писать базы данных. Все знают, что есть куча примеров, те же Kafka и Elastic, написанные на этом языке. Однако честно скажу. Мне все же кажется, что при разработке Кафки наверняка пришлось заниматься лютейшим байтоёбством, выжимать максимум производительности и минимизировать память.
А ебать байты на java всё же в 100 раз сложнее, чем на системных языках, где это всё из коробки.
Поэтому если б я сейчас писал кафку, я бы точно выбрал какой-нибудь Раст.
Отлично поговорили про Канбан-метод с Максимом Фроловым и Алексеем Пименовым
00:00 Приветствие, знакомимся с гостями
2:25 Что такое Канбан-метод и в чем его преимущество?
7:10 Система канбан в Toyota и канбан метод
19:20 WIP лимиты в компании
26:13 Как наложить канбан-метод на вотерфол?
29:09 Зачем что-то менять, если все и так хорошо работает?
36:03 Основные практики канбана
39:59 Нужны ли отдельные тапы и детализация?
41:45 Ограничение незавершённой работы
49:44 Как должен работать WIP
55:21 Upstream и Downstream
1:03:20 WSJF, где начинается скрам и заканчивается канбан?
1:16:56 Скрамбан
1:21:09 Какие рамки у скрамбана ?
1:29:50 Что значит «гибкая методология», и относится ли к ней скрам?
1:34:14 Про классы обслуживания и приоритетность задач
1:38:35 Улучшение процессов
1:42:23 Первое правило внедрение канбан-метода: никто не должен знать про внедрение канбан-метода
1:50:30 Канбан - это про кайдзен? Зачем продавать канбан? (про правильное внедрение)
1:54:13 Мотивация команды, эффективность потока и проблемы скрама
2:05:44 В какой методологии мотивировать проще?
2:08:11 Инструменты для Канбан
2:18:12 Шарманим
https://www.youtube.com/watch?v=9Ms6tx2Sq-4
00:00 Приветствие, знакомимся с гостями
2:25 Что такое Канбан-метод и в чем его преимущество?
7:10 Система канбан в Toyota и канбан метод
19:20 WIP лимиты в компании
26:13 Как наложить канбан-метод на вотерфол?
29:09 Зачем что-то менять, если все и так хорошо работает?
36:03 Основные практики канбана
39:59 Нужны ли отдельные тапы и детализация?
41:45 Ограничение незавершённой работы
49:44 Как должен работать WIP
55:21 Upstream и Downstream
1:03:20 WSJF, где начинается скрам и заканчивается канбан?
1:16:56 Скрамбан
1:21:09 Какие рамки у скрамбана ?
1:29:50 Что значит «гибкая методология», и относится ли к ней скрам?
1:34:14 Про классы обслуживания и приоритетность задач
1:38:35 Улучшение процессов
1:42:23 Первое правило внедрение канбан-метода: никто не должен знать про внедрение канбан-метода
1:50:30 Канбан - это про кайдзен? Зачем продавать канбан? (про правильное внедрение)
1:54:13 Мотивация команды, эффективность потока и проблемы скрама
2:05:44 В какой методологии мотивировать проще?
2:08:11 Инструменты для Канбан
2:18:12 Шарманим
https://www.youtube.com/watch?v=9Ms6tx2Sq-4
YouTube
#112 Говорим о канбан-методе с Максимом Фроловым и Алексеем Пименовым
Мужики затёрли про канбан
00:00 Приветствие, знакомимся с гостями
2:25 Что такое Канбан-метод и в чем его преимущество?
7:10 Система канбан в Toyota и канбан метод
19:20 WIP лимиты в компании
26:13 Как наложить канбан-метод на вотерфол?
29:09 Зачем что-то…
00:00 Приветствие, знакомимся с гостями
2:25 Что такое Канбан-метод и в чем его преимущество?
7:10 Система канбан в Toyota и канбан метод
19:20 WIP лимиты в компании
26:13 Как наложить канбан-метод на вотерфол?
29:09 Зачем что-то…
Forwarded from OpenNews
Демонстрация атаки на редакторы кода, приводящей к утечке файлов при открытии исходных текстов
Продемонстрирован метод атаки на редактор кода VSCode, позволяющий передать произвольные системные файлы при открытии в редакторе специально оформленного исходного кода. В предложенной демонстрации при открытии кода на языке Rust, в котором используется процедурный макрос, выполняется установка соединения с хостом 127.0.0.1:8080 и отправка содержимого файла "~/.ssh/id_rsa" с SSH-ключами пользователя.
Продемонстрирован метод атаки на редактор кода VSCode, позволяющий передать произвольные системные файлы при открытии в редакторе специально оформленного исходного кода. В предложенной демонстрации при открытии кода на языке Rust, в котором используется процедурный макрос, выполняется установка соединения с хостом 127.0.0.1:8080 и отправка содержимого файла "~/.ssh/id_rsa" с SSH-ключами пользователя.
Forwarded from Пятиминутка PHP
Как оптимизировать запрос выбирающий три случайные записи `SELECT * FROM repositories ORDER BY RANDOM() LIMIT 3`? В статье рассмотрены несколько способов с описанием плюсов и минусов. Неожиданное решение: использовать SP-GiST индекс (PostgreSQL): http://amp.gs/jIG1v
ALTER TABLE repositories ADD COLUMN randomness point;
UPDATE opendor SET randomness = point(random(), random());
CREATE INDEX repositories_randomness on repositories using spgist(randomness);
SELECT * FROM repositories ORDER BY randomness <→ point(0.753,0.294) LIMIT 3;
ALTER TABLE repositories ADD COLUMN randomness point;
UPDATE opendor SET randomness = point(random(), random());
CREATE INDEX repositories_randomness on repositories using spgist(randomness);
SELECT * FROM repositories ORDER BY randomness <→ point(0.753,0.294) LIMIT 3;
Разработка на PHP быстрее, чем на Go. На Go - быстрее, чем на Rust.
Но... какая нахер разница. Все равно сделанная задача чего-то ждет: проверки QA, код ревью, админов, деплоя, согласования, слота в канбане и т.д и т.п. Какая разница, ты прогал 2 часа или 5, если потом всё это 5 дней маринуется?
Исключение: когда внедрена культура devops на максималках: trunk-based development, тестирование только автоматическое и оч быстрое, доступ к проду у всех или типа того. Но это редко, и даже тут задача чего-то может ждать.
Так что не ебите мозг, хватит ныть, пишите уже на Расте.
Но... какая нахер разница. Все равно сделанная задача чего-то ждет: проверки QA, код ревью, админов, деплоя, согласования, слота в канбане и т.д и т.п. Какая разница, ты прогал 2 часа или 5, если потом всё это 5 дней маринуется?
Исключение: когда внедрена культура devops на максималках: trunk-based development, тестирование только автоматическое и оч быстрое, доступ к проду у всех или типа того. Но это редко, и даже тут задача чего-то может ждать.
Так что не ебите мозг, хватит ныть, пишите уже на Расте.
Forwarded from Так говорил 2Pizza
Please open Telegram to view this post
VIEW IN TELEGRAM
Кажется, у нас появилась рубрика "читатели пишут".
Вопрос такой, переформулирую своими словами.
Что делать со слишком инициативным сотрудником (джуном), который порой откладывает поставленные задачи, приносящие бизнесу деньги, а вместо этого пытается решить второстепенные проблемы (которые считает почему то суперважными) написанием супермегатулзы. Причем эта тулза, как я понял, еще и по качеству не очень. И поддерживать ее кто будет - непонятно. Т.е. постоянно приходится товарища мягко спускать с небес на землю.
При этом на митингах еще и в уши всем срёт, какой он крутой.
Т.е. в целом хочется не убить жестким контролем инициативу полностью, но при этом не тратить столько времени и нервов на управление. Чтобы инициатива была более осмысленная.
@eantonov, что скажешь?
Вопрос такой, переформулирую своими словами.
Что делать со слишком инициативным сотрудником (джуном), который порой откладывает поставленные задачи, приносящие бизнесу деньги, а вместо этого пытается решить второстепенные проблемы (которые считает почему то суперважными) написанием супермегатулзы. Причем эта тулза, как я понял, еще и по качеству не очень. И поддерживать ее кто будет - непонятно. Т.е. постоянно приходится товарища мягко спускать с небес на землю.
При этом на митингах еще и в уши всем срёт, какой он крутой.
Т.е. в целом хочется не убить жестким контролем инициативу полностью, но при этом не тратить столько времени и нервов на управление. Чтобы инициатива была более осмысленная.
@eantonov, что скажешь?
Накатал статейку на хабр про когнитивные искажения
https://habr.com/ru/company/karuna/blog/555270/
https://habr.com/ru/company/karuna/blog/555270/
Хабр
Когнитивные искажения с примерами для айтишников
Про когнитивные искажения много пишут и много говорят. Однако всегда не хватало более чёткого понимания, как именно это влияет на профессиональную деятельность, мою и моих коллег. Какие решения я как...
Есть маленькие классные нераскрученные каналы в tg, где попадается интересная инфа
Forwarded from Shit books (Maxi Frolof)
И снова привет!
Заключительный пост, привезенный из отпуска. Статья Винстона Ройса “Managing the development of large software systems”. Написана в 1970 году, недавно юбилей был. Прочитал по совету моего другана Фредерика Брукса. Читал 20 минут - камон, это статья.
Ройс пишет, что фундаментально процесс производства маленькой софтины состоит из двух шагов, “Анализ” и “Производство“. Для большой софтверной системы шагов больше. Пример смотрите на скриншоте 1.
Правда, скриншот что-то напоминает? Не буду томить - это классическое и, вероятно, первое изображение так называемого каскадного (водопадного) процесса. Интересно здесь то, что Ройс приводит это изображение в качестве примера и сразу же пишет, что подобный процесс неминуемо привёл бы к провалу. Вот так новости! Первый раз упомянули водопад и сразу провал? Почему так печально?
Все от того, что обратная связь из поздних этапов разработки имеет высокие шансы уничтожить плоды трудов предыдущих этапов. Так называемые “хвостовые риски” появляются в момент, когда работа вроде бы почти завершена. Эта обратная связь отправляется на предыдущий этап в виде “у вас тут не работает как описано“. Хорошо, если можно поправить и забыть. Но что, если поправить нельзя? Что, если надо менять архитектуру еще выше по потоку? Это уже совсем другие затраты времени и денег! Почему мы не узнали об этом раньше? Смотрите схему реальной обратной связи на скриншоте 2.
Что делать в таком случае? Ройс предлагает знакомый вариант. Если хотите, назовите его MVP. Он говорит, что если бы мы могли ввести стадию “предварительной реализации“, то там мы заранее увидели бы хотя бы намеки на хвостовые риски. Смотрите скриншот 3. Напоминает что-нибудь? Подскажу - вероятно, это одно из самых ранних изображений гибкого процесса с итеративно-инкрементальной моделью.
Так где же мы свернули не туда? Если статья, впервые упомянувшая каскадную модель сразу же разносит ее в пух и прах. Если эта же статья предлагает нам более безопасное итеративное производство - откуда берется спор об эффективности водопадов?
Ответ простой и глупый одновременно. Уже в восьмидесятые, через 18 лет после выпуска статьи, Министерство Обороны США искало себе удобный и логичный метод разработки софта. В статье Ройса, на скриншоте 1, они увидели рекламу каскадной модели. Так этот метод и получил официальное признание - в доктрине DOD-STD-2167A какой-то офисный клерк сказал, что софт надо разрабатывать каскадно. Оттуда это утекло в доктрину НАТО. А оттуда в разработку по всему миру.
Морали тут нет. Небольшое предложение от меня: когда в следующий раз встретите спор о преимуществах каскадной модели в разработке, вспомните, что даже ее якобы создатель Ройс сразу же заклеймил такой подход нерабочим. Более того, каноничное изображение с первого скриншота - никакой не каскад водопадов. Ройс просто подумал, что такая визуализация будет понятнее для целей статьи.
Прикладываю официальную ссылочку для ознакомления со статьей
Заключительный пост, привезенный из отпуска. Статья Винстона Ройса “Managing the development of large software systems”. Написана в 1970 году, недавно юбилей был. Прочитал по совету моего другана Фредерика Брукса. Читал 20 минут - камон, это статья.
Ройс пишет, что фундаментально процесс производства маленькой софтины состоит из двух шагов, “Анализ” и “Производство“. Для большой софтверной системы шагов больше. Пример смотрите на скриншоте 1.
Правда, скриншот что-то напоминает? Не буду томить - это классическое и, вероятно, первое изображение так называемого каскадного (водопадного) процесса. Интересно здесь то, что Ройс приводит это изображение в качестве примера и сразу же пишет, что подобный процесс неминуемо привёл бы к провалу. Вот так новости! Первый раз упомянули водопад и сразу провал? Почему так печально?
Все от того, что обратная связь из поздних этапов разработки имеет высокие шансы уничтожить плоды трудов предыдущих этапов. Так называемые “хвостовые риски” появляются в момент, когда работа вроде бы почти завершена. Эта обратная связь отправляется на предыдущий этап в виде “у вас тут не работает как описано“. Хорошо, если можно поправить и забыть. Но что, если поправить нельзя? Что, если надо менять архитектуру еще выше по потоку? Это уже совсем другие затраты времени и денег! Почему мы не узнали об этом раньше? Смотрите схему реальной обратной связи на скриншоте 2.
Что делать в таком случае? Ройс предлагает знакомый вариант. Если хотите, назовите его MVP. Он говорит, что если бы мы могли ввести стадию “предварительной реализации“, то там мы заранее увидели бы хотя бы намеки на хвостовые риски. Смотрите скриншот 3. Напоминает что-нибудь? Подскажу - вероятно, это одно из самых ранних изображений гибкого процесса с итеративно-инкрементальной моделью.
Так где же мы свернули не туда? Если статья, впервые упомянувшая каскадную модель сразу же разносит ее в пух и прах. Если эта же статья предлагает нам более безопасное итеративное производство - откуда берется спор об эффективности водопадов?
Ответ простой и глупый одновременно. Уже в восьмидесятые, через 18 лет после выпуска статьи, Министерство Обороны США искало себе удобный и логичный метод разработки софта. В статье Ройса, на скриншоте 1, они увидели рекламу каскадной модели. Так этот метод и получил официальное признание - в доктрине DOD-STD-2167A какой-то офисный клерк сказал, что софт надо разрабатывать каскадно. Оттуда это утекло в доктрину НАТО. А оттуда в разработку по всему миру.
Морали тут нет. Небольшое предложение от меня: когда в следующий раз встретите спор о преимуществах каскадной модели в разработке, вспомните, что даже ее якобы создатель Ройс сразу же заклеймил такой подход нерабочим. Более того, каноничное изображение с первого скриншота - никакой не каскад водопадов. Ройс просто подумал, что такая визуализация будет понятнее для целей статьи.
Прикладываю официальную ссылочку для ознакомления со статьей
Forwarded from Pro WEB & IT
Недавно озадачился идеей отключить eval в PHP8. В итоге поисков решения накатал свое простейшее расширение на С, которое делает простую вещь - ломает eval
https://tech.geekjob.ru/disable-evil-eval-in-php-8/
https://tech.geekjob.ru/disable-evil-eval-in-php-8/
Medium
Fullstack CTO – Medium
Read writing from Fullstack CTO on Medium. CTO and co-founder at NEWHR & Geekjob. Every day, Fullstack CTO and thousands of other voices read, write, and share important stories on Medium.