Едва ли можно использовать здесь эпитет "идеальный", но мне кажется максимально хороший выбор именно для первого языка прикладного (не системного) программирования сегодня — Python.
Достаточно прямой синтаксис, всякие интересные радости вроде рефлексии и декораторов, реально широкий набор библиотек: веб, графики, ML, всё на свете.
Всё это даёт шанс и научиться программировать (алгоритмы, структуры данных, вот это всё), и при этом с этими знаниями и тем же инструментом войти в отрасль, несколько сглаживая шок от того, насколько этот ваш Pascal далёк от того, за что сегодня в среднем платят деньги.
И вот с этим знанием уже можно более обоснованно выбирать, чем именно интересно заниматься дальше.
Пирамида тестирования — это неплохо.
Но я говорю несколько о другом — корректное функционирование частей (прохождение unit-тестов), не влечёт корректного функционирования всей системы (прохождение e2e тестов).
И с этой точки зрения для продукта гораздо важнее e2e тесты, нежели unit-тесты.
Приехали :)
Кажется программисты писали статью.
Придерживаюсь взгляда, что с точки зрения продукта (а обычно это означает, что и денег тоже), самые важные тесты — это e2e.
Потому что то, что там внутри написал отдел разработки, на каких хаскелях, какими тестами покрыл, в какие докеры завернул — это все безусловно важно. Отделу разработки.
А вот продукт должен просто работать и удовлетворять требованиям конечного пользователя, который не знает ничего о докерах, хаскелях и красоте и пользе гексагональной архитектуры.
Как на каждый релиз в сложном продукте проверять регрессии?
Ну к слову, на мой непрофессиональный взгляд, подавляющее большинство пробок в Омске можно было бы решить построив две-три неблокирующие развязки на весь город. Скорее всего это дорого, но я уверен, что это сильно дешевле метро.
Ну, не знаю, ребята, как вы всё это видите, но я вижу что iPad стал тем, что можно назвать "Персональный компьютер" — личный компьютер человека для личных дел: почта, новости, чтение, музыка, сопутствующие активности.
А тот, компьютер, который был "Персональным компьютером" стал "Рабочим компьютером". Там и тонны разной периферии, и зоопарк самого разного софта, и всё что хочется.
Может ли iPad быть "Рабочим компьютером"? Ну, допускаю, что кое-где может.
Оправдал ли он ожидания? Тут, конечно вопрос в том, чьи ожидания, но раздав всем родителям по айпэду, я вижу довольные лица и не слышу никаких вопросов после курса молодого бойца, а каждый раз открывая их же ноутбук, слышу тихий вздох.
Так в этом же и состоит искусство быть хорошим программистом и прекрасным менеджером: найти тонкую грань между "очень правильно, но никогда" и "хлоп-хлоп и в продакшн".
Прочитать книжку по AGILE или любой другой аббревиатуре много ума не надо — это же нужно еще и в текущую реальность интегрировать.
Имхо, проблема отсутствия линукс на десктопе в тотальном отсутствии UX за пределами терминала. Пользовательский опыт в терминале понятен, прекрасен и достаточно структурирован. За его пределами гиково, нердово, иногда напильникопригодно, но суть такая, что пользоваться сложно.
Чтобы в меня не выкинули сразу все гнилые помидоры: около 8 лет пользовался линуксами как единственной ОС. Не могу сказать что надоело, попробовал почти случайно MacOS и оказалось, что жить можно лучше, хоть и несколько дороже.
Вообще в пластик можно, но это должен быть специальный пластик со специальной маркировкой.
Чтобы дважды не вставать: в большинстве современных автомобилей бензобак пластиковый.
Но вообще вопрос российскости в целом интересный. Как именно нужно определять, что ПО разработано в России? Как быть с Яндексом из Нидерландов? А страной происхождения glibc какую считать? А условный ООО "Эппл Рус" мог разработать календарь?
Мне отдалённо понятно как это происходит для оборонки, можно предположить, что условно доработанный Postgres мог как минимум пройти некий аудит, и тем самым стать "проверенным в России" на предмет закладок.
Все так и есть. Без проверки доступны только общие методы, с проверкой — методы того типа, на который проверились. Проверять можно обычным if-ом, а можно написать type guard.
В обоих случаях компилятор все понимает, и в теле if-а тип выводит сам.
Есть потрясающая штука для проверки валидности запроса — база данных.
В неё можно пихнуть настоящий запрос, а на выходе получить либо результат, либо приемлемое описание того, что пошло не так (ошибка в синтаксисе, регистре, модели, итд).
Это конечно немного не так быстро, как проверить строчку, но зато чертовски надёжно и по-настоящему.
В докере всё это разворачивается за день вместе с упражнениями по конфигурации каждой базы внутри докера.
Едва ли можно использовать здесь эпитет "идеальный", но мне кажется максимально хороший выбор именно для первого языка прикладного (не системного) программирования сегодня — Python.
Достаточно прямой синтаксис, всякие интересные радости вроде рефлексии и декораторов, реально широкий набор библиотек: веб, графики, ML, всё на свете.
Всё это даёт шанс и научиться программировать (алгоритмы, структуры данных, вот это всё), и при этом с этими знаниями и тем же инструментом войти в отрасль, несколько сглаживая шок от того, насколько этот ваш Pascal далёк от того, за что сегодня в среднем платят деньги.
И вот с этим знанием уже можно более обоснованно выбирать, чем именно интересно заниматься дальше.
Пирамида тестирования — это неплохо.
Но я говорю несколько о другом — корректное функционирование частей (прохождение unit-тестов), не влечёт корректного функционирования всей системы (прохождение e2e тестов).
И с этой точки зрения для продукта гораздо важнее e2e тесты, нежели unit-тесты.
Приехали :)
Кажется программисты писали статью.
Придерживаюсь взгляда, что с точки зрения продукта (а обычно это означает, что и денег тоже), самые важные тесты — это e2e.
Потому что то, что там внутри написал отдел разработки, на каких хаскелях, какими тестами покрыл, в какие докеры завернул — это все безусловно важно. Отделу разработки.
А вот продукт должен просто работать и удовлетворять требованиям конечного пользователя, который не знает ничего о докерах, хаскелях и красоте и пользе гексагональной архитектуры.
Как на каждый релиз в сложном продукте проверять регрессии?
Just for fun?
А вот интересно, почему именно классическая вертолётная схема, а не многовинтовая, вроде квадрокоптеров?
Ну к слову, на мой непрофессиональный взгляд, подавляющее большинство пробок в Омске можно было бы решить построив две-три неблокирующие развязки на весь город. Скорее всего это дорого, но я уверен, что это сильно дешевле метро.
Ну, не знаю, ребята, как вы всё это видите, но я вижу что iPad стал тем, что можно назвать "Персональный компьютер" — личный компьютер человека для личных дел: почта, новости, чтение, музыка, сопутствующие активности.
А тот, компьютер, который был "Персональным компьютером" стал "Рабочим компьютером". Там и тонны разной периферии, и зоопарк самого разного софта, и всё что хочется.
Может ли iPad быть "Рабочим компьютером"? Ну, допускаю, что кое-где может.
Оправдал ли он ожидания? Тут, конечно вопрос в том, чьи ожидания, но раздав всем родителям по айпэду, я вижу довольные лица и не слышу никаких вопросов после курса молодого бойца, а каждый раз открывая их же ноутбук, слышу тихий вздох.
Так в этом же и состоит искусство быть хорошим программистом и прекрасным менеджером: найти тонкую грань между "очень правильно, но никогда" и "хлоп-хлоп и в продакшн".
Прочитать книжку по AGILE или любой другой аббревиатуре много ума не надо — это же нужно еще и в текущую реальность интегрировать.
Только 4к и выше, дюймах так на 27. Больше уже DPI не так высок как хотелось бы.
Но это дорога в одну сторону.
У меня так было: нужен был монитор, решил попробовать 4к. Купил, поставил. Нормально, красиво, работает.
Поработал пару дней. Случайно глянул на старый FullHD монитор перед продажей. Не сразу понял, почему так все мылит и устают глаза.
tifeit а посоветуйте книги почитать по теме?
микрометеорит из ПМ — Пускателя Микрометеоритов?
А вот интересно, у них там свой компилятор тайпскрипта? Язык же довольно динамично развивается. Или внутри по-прежнему JS?
ICCCM это безусловно здорово. Где только засилие качественного гуевого софта, основанного на всём этом?
Имхо, проблема отсутствия линукс на десктопе в тотальном отсутствии UX за пределами терминала. Пользовательский опыт в терминале понятен, прекрасен и достаточно структурирован. За его пределами гиково, нердово, иногда напильникопригодно, но суть такая, что пользоваться сложно.
Чтобы в меня не выкинули сразу все гнилые помидоры: около 8 лет пользовался линуксами как единственной ОС. Не могу сказать что надоело, попробовал почти случайно MacOS и оказалось, что жить можно лучше, хоть и несколько дороже.
Вообще в пластик можно, но это должен быть специальный пластик со специальной маркировкой.
Чтобы дважды не вставать: в большинстве современных автомобилей бензобак пластиковый.
Их выводили из ассортимента, а потом вернули обратно: https://vk.com/topic-17769013_34322211?post=168579
Всё, расслабляйтесь — пока отозвали обратно :)
https://sozd.duma.gov.ru/bill/745970-7
Но вообще вопрос российскости в целом интересный. Как именно нужно определять, что ПО разработано в России? Как быть с Яндексом из Нидерландов? А страной происхождения glibc какую считать? А условный ООО "Эппл Рус" мог разработать календарь?
Мне отдалённо понятно как это происходит для оборонки, можно предположить, что условно доработанный Postgres мог как минимум пройти некий аудит, и тем самым стать "проверенным в России" на предмет закладок.
Все так и есть. Без проверки доступны только общие методы, с проверкой — методы того типа, на который проверились. Проверять можно обычным if-ом, а можно написать type guard.
В обоих случаях компилятор все понимает, и в теле if-а тип выводит сам.
В общем, если сделать шаг в сторону от джавового ООП, то вот так (typescript):
Легко.
Есть потрясающая штука для проверки валидности запроса — база данных.
В неё можно пихнуть настоящий запрос, а на выходе получить либо результат, либо приемлемое описание того, что пошло не так (ошибка в синтаксисе, регистре, модели, итд).
Это конечно немного не так быстро, как проверить строчку, но зато чертовски надёжно и по-настоящему.
В докере всё это разворачивается за день вместе с упражнениями по конфигурации каждой базы внутри докера.