Ну к слову, на мой непрофессиональный взгляд, подавляющее большинство пробок в Омске можно было бы решить построив две-три неблокирующие развязки на весь город. Скорее всего это дорого, но я уверен, что это сильно дешевле метро.
Ну, не знаю, ребята, как вы всё это видите, но я вижу что iPad стал тем, что можно назвать "Персональный компьютер" — личный компьютер человека для личных дел: почта, новости, чтение, музыка, сопутствующие активности.
А тот, компьютер, который был "Персональным компьютером" стал "Рабочим компьютером". Там и тонны разной периферии, и зоопарк самого разного софта, и всё что хочется.
Может ли iPad быть "Рабочим компьютером"? Ну, допускаю, что кое-где может.
Оправдал ли он ожидания? Тут, конечно вопрос в том, чьи ожидания, но раздав всем родителям по айпэду, я вижу довольные лица и не слышу никаких вопросов после курса молодого бойца, а каждый раз открывая их же ноутбук, слышу тихий вздох.
Так в этом же и состоит искусство быть хорошим программистом и прекрасным менеджером: найти тонкую грань между "очень правильно, но никогда" и "хлоп-хлоп и в продакшн".
Прочитать книжку по AGILE или любой другой аббревиатуре много ума не надо — это же нужно еще и в текущую реальность интегрировать.
Имхо, проблема отсутствия линукс на десктопе в тотальном отсутствии UX за пределами терминала. Пользовательский опыт в терминале понятен, прекрасен и достаточно структурирован. За его пределами гиково, нердово, иногда напильникопригодно, но суть такая, что пользоваться сложно.
Чтобы в меня не выкинули сразу все гнилые помидоры: около 8 лет пользовался линуксами как единственной ОС. Не могу сказать что надоело, попробовал почти случайно MacOS и оказалось, что жить можно лучше, хоть и несколько дороже.
Вообще в пластик можно, но это должен быть специальный пластик со специальной маркировкой.
Чтобы дважды не вставать: в большинстве современных автомобилей бензобак пластиковый.
Но вообще вопрос российскости в целом интересный. Как именно нужно определять, что ПО разработано в России? Как быть с Яндексом из Нидерландов? А страной происхождения glibc какую считать? А условный ООО "Эппл Рус" мог разработать календарь?
Мне отдалённо понятно как это происходит для оборонки, можно предположить, что условно доработанный Postgres мог как минимум пройти некий аудит, и тем самым стать "проверенным в России" на предмет закладок.
Все так и есть. Без проверки доступны только общие методы, с проверкой — методы того типа, на который проверились. Проверять можно обычным if-ом, а можно написать type guard.
В обоих случаях компилятор все понимает, и в теле if-а тип выводит сам.
Есть потрясающая штука для проверки валидности запроса — база данных.
В неё можно пихнуть настоящий запрос, а на выходе получить либо результат, либо приемлемое описание того, что пошло не так (ошибка в синтаксисе, регистре, модели, итд).
Это конечно немного не так быстро, как проверить строчку, но зато чертовски надёжно и по-настоящему.
В докере всё это разворачивается за день вместе с упражнениями по конфигурации каждой базы внутри докера.
У меня возникает ощущение, что у вас весьма однобокое представление о разработке и "обычном" веб-проекте.
Если речь идёт о лэндингах, сайтах-визитках и прочем формошлёпстве — вопросов нет, юнит тесты там скорее вредят чем помогают, да и вообще юнит тесты для UI штук это такая немного отдельная история.
Давайте посмотрим на пример поинтереснее. Вот нынче микросервисы в моде. Их обычно каким-нибудь MOM (Message-Oriented Middleware, AWS SQS или RabbitMq какой-нибудь) связывают друг с другом и они по-разному обмениваются сообщениями друг с другом.
Поступило требование: в микросервис, который отвечает за отдачу профиля пользователя (мы все жутко прогрессивные, да), добавить в ответ фамилию пользователя — раньше мы его не отдавали.
Программист что-то там поправил, звёзды сошлись, и оно даже компилируется (пусть дело происходит на Java, чтобы не набежали адепты Idris с немым вопросом "если компилируется, чему там не работать?").
Теперь вопрос: что должно дальше произойти?
Взять дебаггер и посмотреть что происходит? На каких тестовых данных будем проверять? В базу их надо предварительно положить? А запрос из MOM тоже руками отправлять? А как бы убедиться, что это изменение регрессий не добавило, и остальные 146 полей по-прежнему возвращают то, что должны?
Давайте предположим, что мы жутко экономим, и в самом деле заставили живого человека всё это делать руками, а проверять — глазами.
Но мы ведь за экономику тут, верно? А люди иногда ошибаются, да и задачи бывают иногда сложнее, чем добавить одно поле (иногда надо добавить два-три). И с первой итерации дебагово-смотрительного тестирования, дело не очень прошло, база немного испорчена, надо перенакатить заново, бахнуть MOM-запрос руками и посмотреть еще раз.
Сколько таких итераций надо сделать, чтобы разработчик потерял бдительность и стал работать еще медленнее?
Сколько времени и итераций с дебаггером потратит разработчик на проверку всех возможных кейсов (условно, фамилия задана латиницей, фамилия задана кирилицей, фамилия на RTL языке, фамилия не задана)?
Сколько времени потратит следующий разработчик для добавления еще одного следующего поля, на ручные упражнения с регрессией по вышеописанной задаче?
Спору нет, я немного утрировал и перегнул палку — согласно свежим политическим сводкам, кирилицу, конечно можно не проверять. Но, думаю идея ясна.
Мне кажется тут ускользает одна любопытная деталь. А как программист должен проверять, что его код вообще хоть что-то там полезное делает?
Ну вот написал класс, что должно произойти дальше? Можно деплоить на прод глянув на код внимательным прищуром?
Мы на втором курсе ВУЗа все пихали в main() и вызывали. Немного позже снизошло понимание, что этот main() поправленный под нужды запускаемого класса, и есть юнит-тест.
А вот интересно, почему именно классическая вертолётная схема, а не многовинтовая, вроде квадрокоптеров?
Ну к слову, на мой непрофессиональный взгляд, подавляющее большинство пробок в Омске можно было бы решить построив две-три неблокирующие развязки на весь город. Скорее всего это дорого, но я уверен, что это сильно дешевле метро.
Ну, не знаю, ребята, как вы всё это видите, но я вижу что 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):
Легко.
Есть потрясающая штука для проверки валидности запроса — база данных.
В неё можно пихнуть настоящий запрос, а на выходе получить либо результат, либо приемлемое описание того, что пошло не так (ошибка в синтаксисе, регистре, модели, итд).
Это конечно немного не так быстро, как проверить строчку, но зато чертовски надёжно и по-настоящему.
В докере всё это разворачивается за день вместе с упражнениями по конфигурации каждой базы внутри докера.
А если у меня нетривиальный DAO, который ходит в базу, тесты для него юнит или интеграционные?
У меня возникает ощущение, что у вас весьма однобокое представление о разработке и "обычном" веб-проекте.
Если речь идёт о лэндингах, сайтах-визитках и прочем формошлёпстве — вопросов нет, юнит тесты там скорее вредят чем помогают, да и вообще юнит тесты для UI штук это такая немного отдельная история.
Давайте посмотрим на пример поинтереснее. Вот нынче микросервисы в моде. Их обычно каким-нибудь MOM (Message-Oriented Middleware, AWS SQS или RabbitMq какой-нибудь) связывают друг с другом и они по-разному обмениваются сообщениями друг с другом.
Поступило требование: в микросервис, который отвечает за отдачу профиля пользователя (мы все жутко прогрессивные, да), добавить в ответ фамилию пользователя — раньше мы его не отдавали.
Программист что-то там поправил, звёзды сошлись, и оно даже компилируется (пусть дело происходит на Java, чтобы не набежали адепты Idris с немым вопросом "если компилируется, чему там не работать?").
Теперь вопрос: что должно дальше произойти?
Взять дебаггер и посмотреть что происходит? На каких тестовых данных будем проверять? В базу их надо предварительно положить? А запрос из MOM тоже руками отправлять? А как бы убедиться, что это изменение регрессий не добавило, и остальные 146 полей по-прежнему возвращают то, что должны?
Давайте предположим, что мы жутко экономим, и в самом деле заставили живого человека всё это делать руками, а проверять — глазами.
Но мы ведь за экономику тут, верно? А люди иногда ошибаются, да и задачи бывают иногда сложнее, чем добавить одно поле (иногда надо добавить два-три). И с первой итерации дебагово-смотрительного тестирования, дело не очень прошло, база немного испорчена, надо перенакатить заново, бахнуть MOM-запрос руками и посмотреть еще раз.
Сколько таких итераций надо сделать, чтобы разработчик потерял бдительность и стал работать еще медленнее?
Сколько времени и итераций с дебаггером потратит разработчик на проверку всех возможных кейсов (условно, фамилия задана латиницей, фамилия задана кирилицей, фамилия на RTL языке, фамилия не задана)?
Сколько времени потратит следующий разработчик для добавления еще одного следующего поля, на ручные упражнения с регрессией по вышеописанной задаче?
Спору нет, я немного утрировал и перегнул палку — согласно свежим политическим сводкам, кирилицу, конечно можно не проверять. Но, думаю идея ясна.
Мне кажется тут ускользает одна любопытная деталь. А как программист должен проверять, что его код вообще хоть что-то там полезное делает?
Ну вот написал класс, что должно произойти дальше? Можно деплоить на прод глянув на код внимательным прищуром?
Мы на втором курсе ВУЗа все пихали в main() и вызывали. Немного позже снизошло понимание, что этот main() поправленный под нужды запускаемого класса, и есть юнит-тест.
Наушники и в самом деле одни из лучших в своем сегменте.