Снова возвращаемся к интересной теме Web3 - доклад про IPFS. Это децентрализованная файловая система, которая позволяет хранить и получать файлы без центрального сервера, используя сеть узлов, которые обмениваются данными по специальному протоколу. Её относительно успешно внедрили у себя на хостинге компания SpaceWeb, о чём и рассказывал спикер.
Несомненно, это один из самых интересных и одновременно спорных докладов - спикеру было задано очень много вопросов о безопасности, экономической целесообразности и других проблемах наличия IPFS на хостинге (их там много, ещё и пользователи используют её не только для контента). Но то, что даже компании в такой консервативной предметной области внедряют новые технологии не может не радовать!
Несомненно, это один из самых интересных и одновременно спорных докладов - спикеру было задано очень много вопросов о безопасности, экономической целесообразности и других проблемах наличия IPFS на хостинге (их там много, ещё и пользователи используют её не только для контента). Но то, что даже компании в такой консервативной предметной области внедряют новые технологии не может не радовать!
👍3
Третий доклад был про мой любимый .NET, а точнее про полиморфные контракты и сериализацию JSON. Доклад довольно простенький, хоть и провёл его очень крутой разработчик (он кстати ведёт свой блог StepOne). Однако я узнал об интересной фишке System.Text.Json в .NET7, а ещё автор провёл бенчмарк и сравнил эту библиотеку со стандартом - Newtonsoft.Json. Было интересно
👍4🔥1
Далее - один из докладов, который немного меня разочаровал :(
Он назывался "Инструменты архитектора в современной практике". И я ожидал, что будут конкретные примеры инструментов (кейсы использования, необычные решения и программы и всё такое). А получил доклад о том, что
1. Главный инструмент архитектора - это коммуникации
2. Коммуникации бывают разные и с разными людьми
3. Инструменты должны облегчать коммуникации и упрощать принятие решений
Круто конечно, но я хотел конкретики и примеров, а не сухой теории о том, кто такой архитектор :(
Он назывался "Инструменты архитектора в современной практике". И я ожидал, что будут конкретные примеры инструментов (кейсы использования, необычные решения и программы и всё такое). А получил доклад о том, что
1. Главный инструмент архитектора - это коммуникации
2. Коммуникации бывают разные и с разными людьми
3. Инструменты должны облегчать коммуникации и упрощать принятие решений
Круто конечно, но я хотел конкретики и примеров, а не сухой теории о том, кто такой архитектор :(
😢3👍1
Следующий доклад был в блоке про DevOps.
Спикер рассказывал про метрики для хостингов (для серверов, ЦОДов и т.д.). О том, как они эти метрики хранят и работают с ними. Из интересного - был небольшой "интерактив" с залом на тему того, как конвертировать мегабиты в рубли (ответа так и не получили). И прикольная комбинация для метрик - Zabbix + PostgreSQL + Grafana. О такой комбинации раньше я не слышал, хочется теперь попробовать развернуть это всё и потыкать)
Спикер рассказывал про метрики для хостингов (для серверов, ЦОДов и т.д.). О том, как они эти метрики хранят и работают с ними. Из интересного - был небольшой "интерактив" с залом на тему того, как конвертировать мегабиты в рубли (ответа так и не получили). И прикольная комбинация для метрик - Zabbix + PostgreSQL + Grafana. О такой комбинации раньше я не слышал, хочется теперь попробовать развернуть это всё и потыкать)
🔥3👍1
Далее - два доклада про безопасность.
Первый - про баланс между ИТ и ИБ, и про то, как убедить бизнес заниматься этим ИБ (с конкретными примерами: отговорка -> действия). Кажется, до сих пор с этим есть проблемы.
На этом докладе я узнал про целый рынок Ransomware as a Service, про хактивистов, ну и про то, как организовывать ИБ в компании. Эта тема пересекалась с одним докладом первого дня
Второй доклад - про безопасность kubernetes. Узнал про пару ГОСТов по безопасности (не спрашивайте зачем), про вызовы и подходы к безопасности k8s, но в целом там было что-то вроде "делайте network policy и не светите секретами, используйте сертифицированное ПО и всё будет ок"
Первый - про баланс между ИТ и ИБ, и про то, как убедить бизнес заниматься этим ИБ (с конкретными примерами: отговорка -> действия). Кажется, до сих пор с этим есть проблемы.
На этом докладе я узнал про целый рынок Ransomware as a Service, про хактивистов, ну и про то, как организовывать ИБ в компании. Эта тема пересекалась с одним докладом первого дня
Второй доклад - про безопасность kubernetes. Узнал про пару ГОСТов по безопасности (не спрашивайте зачем), про вызовы и подходы к безопасности k8s, но в целом там было что-то вроде "делайте network policy и не светите секретами, используйте сертифицированное ПО и всё будет ок"
👍1
В целом, конференция - огонь. Мерч, эмоции, общение и классные доклады... Да и в целом неплохой идеей было уехать в Ульяновск и немного развеяться )
Мне всё понравилось, и я надеюсь, что попаду и на следующую Стачку) Спасибо организаторам и спикерам!
Мне всё понравилось, и я надеюсь, что попаду и на следующую Стачку) Спасибо организаторам и спикерам!
👍9🔥3
Logseq: новое приложение для заметок, которое я попробовал на конференции
На конференции "Стачка" я также попробовал новое приложение для заметок - Logseq. Это приложение-аутлайнер, в котором каждая заметка - это маркированный список. В нём можно ссылаться на другие блоки в нумерованном списке, а также на другие заметки - чтобы из них получался некоторый граф.
Конспектировать доклады в виде списка тезисов с пунктами, подпунктами и подпунктами подпунктов оказалось очень удобно. Обычно наши конспекты (в школе, на лекциях в вузе) - это просто сплошной текст, но список более приятный и структурированный, о чём я раньше даже не задумывался.
В целом приложением я не планирую пользоваться в дальнейшем по двум причинам - в нём нет папок, и это не позволяет удобно разделять конспекты по разным темам, и основная масса заметок у меня в другом месте. Однако вполне возможно что-то изменится, и я начну использовать logseq. Например там очень удобные canvas-заметки )
В любом случае я рекомендую его попробовать тем, кто любит заметковедение и всю эту тему)
#приложения
Flexible Coding
На конференции "Стачка" я также попробовал новое приложение для заметок - Logseq. Это приложение-аутлайнер, в котором каждая заметка - это маркированный список. В нём можно ссылаться на другие блоки в нумерованном списке, а также на другие заметки - чтобы из них получался некоторый граф.
Конспектировать доклады в виде списка тезисов с пунктами, подпунктами и подпунктами подпунктов оказалось очень удобно. Обычно наши конспекты (в школе, на лекциях в вузе) - это просто сплошной текст, но список более приятный и структурированный, о чём я раньше даже не задумывался.
В целом приложением я не планирую пользоваться в дальнейшем по двум причинам - в нём нет папок, и это не позволяет удобно разделять конспекты по разным темам, и основная масса заметок у меня в другом месте. Однако вполне возможно что-то изменится, и я начну использовать logseq. Например там очень удобные canvas-заметки )
В любом случае я рекомендую его попробовать тем, кто любит заметковедение и всю эту тему)
#приложения
Flexible Coding
🔥4
Flexible Coding
Всем привет! Расскажу вам о небольшой полезной фишке IDE от Jetbrains - IDEA Shelf. Этот механизм позволяет сохранять код, который вы еще не закоммитили, чтобы возвращаться к нему позже. Как использовать? - В окне Commit щелкните ПКМ по файлам или списку изменений…
Всем привет!
Недавно я писал про инструмент Idea Shelf. Он полезный, но имеет большой недостаток - привязка к IDE от JetBrains.
Система контроля версий Git предоставляет свой инструмент для того, чтобы сохранять изменения вне коммитов по аналогии с Shelve - git stash. В новой статье я разобрал этот инструмент.
#статьи
Flexible Coding
Недавно я писал про инструмент Idea Shelf. Он полезный, но имеет большой недостаток - привязка к IDE от JetBrains.
Система контроля версий Git предоставляет свой инструмент для того, чтобы сохранять изменения вне коммитов по аналогии с Shelve - git stash. В новой статье я разобрал этот инструмент.
#статьи
Flexible Coding
Timeweb Cloud
Лучшие практики по использованию команды git stash
Лучшие практики по использованию команды git stash. Блог Timeweb Cloud: дайджесты, новости компании, IT и облачные тренды.
🔥5
🚀 Практикум в Вологодском колледже связи
Привет, друзья! Недавно я от имени компании Skillaz провел практикум в Вологодском колледже Связи и информационных технологий - рассказал студентам о протоколе HTTP и его применении
Что мы делали:
1. Разбирали основы протокола HTTP
2. Тыкались в Swagger
3. Интегрировались со скиллаз на примере реального кейса
Для меня это был первый подобный опыт, и могу сказать что всё удалось! Естественно, были и недочёты, которые я обязательно учту для следующих подобных мероприятий, но прям критичные проблемы отсутствовали )
Спасибо всем, кто был с нами!
Flex Code
Привет, друзья! Недавно я от имени компании Skillaz провел практикум в Вологодском колледже Связи и информационных технологий - рассказал студентам о протоколе HTTP и его применении
Что мы делали:
1. Разбирали основы протокола HTTP
2. Тыкались в Swagger
3. Интегрировались со скиллаз на примере реального кейса
Для меня это был первый подобный опыт, и могу сказать что всё удалось! Естественно, были и недочёты, которые я обязательно учту для следующих подобных мероприятий, но прям критичные проблемы отсутствовали )
Спасибо всем, кто был с нами!
Flex Code
🔥20👍4❤🔥1💘1
Неожиданные детали реализации структур данных
Недавно на работе делал небольшой workflow-движок. Это такой механизм, в который можно засунуть набор некоторых действий с возможностью отката и выполнить их в единый момент времени. Все эти действия складывались в очередь - и я решил использовать Prority Queue, а к действиям добавить кастомизируемый приоритет (возможность указать
Итого я построил процесс, в котором было много действий с одинаковым приоритетом и одно Last, которое выполняется последним (см схемку). Написал какие-то тесты, вроде всё работает. Использую движок в конкретном бизнес-процессе, заливаю в прод, кайфую.
Проходит время, и коллегам из соседней команды заводят баг на тему того, что что-то где-то выполняется не в том порядке и возникают кривые данные. Коллеги изучают, и внезапно в PriorityQueue НЕ ГАРАНИРУЕТСЯ ПОРЯДОК ПОЛУЧЕНИЯ ЭЛЕМЕНТОВ С ОДИНАКОВЫМ ПРИОРИТЕТОМ! В общем, действия выполнялись в рандомном порядке, и потенциально (мы так и не убедились в этом на 100%) система порождала кривые данные
Какой можно сделать вывод?
- Структуры данных надо знать, я их знаю, я молодец. Но было бы неплохо читать ремарки в документации
- Тесты не панацея - они, в общем-то, были написаны, но покрывали недостаточно кейсов (кто ж знал что порядок не гарантируется)
- Чего-то не знать - это нормально, как и допускать ошибки. Главное - нести ответственность за свои решения и здраво воспринимать обратную связь
#кейсы
Flex Code
Недавно на работе делал небольшой workflow-движок. Это такой механизм, в который можно засунуть набор некоторых действий с возможностью отката и выполнить их в единый момент времени. Все эти действия складывались в очередь - и я решил использовать Prority Queue, а к действиям добавить кастомизируемый приоритет (возможность указать
Priority.Last и гарантировать, что действие выполнится последним). Звучит надёжно!Итого я построил процесс, в котором было много действий с одинаковым приоритетом и одно Last, которое выполняется последним (см схемку). Написал какие-то тесты, вроде всё работает. Использую движок в конкретном бизнес-процессе, заливаю в прод, кайфую.
Проходит время, и коллегам из соседней команды заводят баг на тему того, что что-то где-то выполняется не в том порядке и возникают кривые данные. Коллеги изучают, и внезапно в PriorityQueue НЕ ГАРАНИРУЕТСЯ ПОРЯДОК ПОЛУЧЕНИЯ ЭЛЕМЕНТОВ С ОДИНАКОВЫМ ПРИОРИТЕТОМ! В общем, действия выполнялись в рандомном порядке, и потенциально (мы так и не убедились в этом на 100%) система порождала кривые данные
Какой можно сделать вывод?
- Структуры данных надо знать, я их знаю, я молодец. Но было бы неплохо читать ремарки в документации
- Тесты не панацея - они, в общем-то, были написаны, но покрывали недостаточно кейсов (кто ж знал что порядок не гарантируется)
- Чего-то не знать - это нормально, как и допускать ошибки. Главное - нести ответственность за свои решения и здраво воспринимать обратную связь
#кейсы
Flex Code
👍7