Мне для сложных случаев проще использовать командую строку с ack-grep или аналогом (silversearcher, да много их). Если поиска в Idea недостаточно, то в командной строке я могу быстро набросать любую возможную комбинацию из find, ack, xargs, grep.
Мне это как-то проще, чем целиться мышкой в десятки чекбоксов.
А для физических лиц есть? Я люблю путешествовать на мото в одиночку по безлюдным местам, и эта тема меня интересует. Пока нарыл только трекеры Spot и Garmin InReach. Spot дешевле, и им пользуется огромное количество путешественников.
Кстати, JetHabr, возможно вам Spot также подойдет — у них покрытие почти по всему земному шару.
Другое дело, что разработчики «домашних страниц» (тогда и корпоративные сайты частенько так назывались, так что никакого наброса) люто-бешено любили shared хостинги :)
Стоит тогда вспомнить, что тогда не-shared хостинги были очень редки и стоили в несколько раз (возможно, на порядок) дороже shared хостингов.
А Zope была мега-крутой штукой, просто космос, по сравнению со всем остальным, что тогда было. Но с определенными недостатками. Меня больше всего бесило редактирование TTW, которое в браузерах того времени просто не могло работать нормально. Потом появился ExternalEditor, но это было уже когда эпоха Zope начала клониться к закату.
Ну и ни один проект на Zope почти не взлетел, так как требовалась серьезная квалификация разработчиков. Особенно, когда пошли Plone и Zope 3. Документации толковой не было, книг тоже, все приходилось изучать по исходному коду.
Знакомый (не знаю, есть ли он на Хабре) когда-то сделал мощный портал на Zope 3, потом жаловался, что для поддержки и развития не удалось найти ни одного разработчика — слишком сложная архитектура.
Да что там говорить, до сих пор львиная доля сайтов делается на PHP и Javascript, и вовсе не потому, что эти языки имеют весомые преимущества. Скорее потому, что любой может осилив 5 строк введения начать лабать на этих языках сайты, пускай это спагетти-код, пускай там тоннами используются неинициализированные переменные, и т.д. Не требуется знать ничего: садись да пиши.
У меня в 4-х летнем ноутбуке есть разъем с поддержкой гарнитуры. Только мне пока не удалось найти гарнитуру, которая к нему бы подходила (специально не искал, но телефонная не работает — звук не пишется).
Я, к сожалению, очень мало что знаю об архитектуре современных процессоров. Но на Hacker News прочитал комментарий (без пруфов), что в Itanium эти атаки были бы невозможны.
К сожалению, укрупнение и монополизация приводят к некрасивым результатам. Если у нас остался один производитель процессоров, то в случае серьезной уязвимости, нам некуда деться.
Если нас забанил Google, то это для некоторых людей может быть почти тем же самым, что и быть забаненым в Интернет.
Не проще ли для поездов передавать энергию по проводам, как это делается с незапамятных времен? Я понимаю топливные элементы в авто — авто может заехать куда угодно. Но поезда то движутся всегда по одним и тем же дорогам, которые можно электрифицировать, и это наверняка проще и дешевле.
Нет, дело именно в том, что устройство не подключается. В панели Gnome оно отображается как сопряженное, на секунду подключается и тут же отключается.
Я планирую посмотреть как-нибудь, что при этом пишется в логи, просто сейчас на это совсем нет времени.
Но это просто из последнего. А так у меня вообще, весь опыт взаимодействия bluetooth устройств с Linux исключительно негативный. Все время что-нибудь не работает.
Впрочем, когда у меня была девушка, а у нее был ноутбук с Windows, там с BT тоже были вечные проблемы. Так что возможно дело в самой технологии Bluetooth, а не конкретных реализациях.
Почему нет? Вот даже в США, которых многие на Хабре считают образцом во всем, в US Air Force решили писать код сами. Конечно, не только они пишут, просто это первое что вспомнилось, так как об этом недавно писали на Hacker News.
Невозможно создать универсальный инструмент, подходящий для абсолютно всех ситуаций. Нельзя болгаркой и ремонтировать авто, и строить дома.
Если вы интересуетесь авто-мото темой, то наверняка заметили, что львиная доля трепотни об авто — это обсуждения наподобие: «Как жаль, что нет авто, с двигателем, который проезжает 1,000,000 км без капиталки, который отлично управляется на треке, в городе, и проезжает в болоте, да еще, чтобы стоил дешевле $20,000 и налоги на него были невысокие». Или в мото: «Хочу турэндуро с движком 1,5 л и 200 лошадей, чтобы и на треке гонять, и в выходные по лесу. И с запасом хода от 500 км. При этом быть легче 150 кг, легко рулиться, и быть невысоким».
Начиная с какого-то момента требования становятся противоречивыми. Можно увеличить мощность, но это увеличит вес и стоимость и снизит надежность. Можно снизить вес, но для этого придется использовать менее мощный мотор и более дорогие материалы (легкие сплавы вместо стали).
Выхода два: использовать несколько инструментов, каждый для своей задачи, или мириться с недостатками, при использовании не по назначению.
Если бы существовал идеальный инструмент для всех задач, то все бы на него перешли, и language holywars ушли бы в прошлое.
Ой, ну прям быть мелкой конторой — это серебряная пуля. Решает абсолютно все проблемы.
Если что, в мелких конторах еще больше нехватка разработчиков, и часто качество и безопасность приносится в жертву «business requirements».
Разработчик: «У нас здесь SQL injection в унаследованном коде, который мы купили у компании А»
Менеджер: «Твоя задача на сегодня починить форму Б в модуле С. Это важная задача для бизнеса. Через два месяца мы выкатим новую версию, тогда у тебя будет время, чтобы исправить эту injection и остальные баги».
Но естественно, через два месяца будет какой-то другой аврал, и все баги, дыры, и так далее копятся до бесконечности.
У меня вообще Bluetooth никогда не работал нормально. Просто вообще никогда. Разные устройства, разное железо, разные ядра, всегда все или не находится, или не сопрягается, или отваливается через 1 минуту.
Вот и сейчас у меня есть Bluetooth колонка. С телефоном на Android (который тот же Linux) она работает. А с Ubuntu 18.04 — нет. После первого сопряжения работает, но если выключить и включить колонку или ноутбук, то уже не работает. Приходится вручную удалять сопряжение и сопрягать заново каждый раз, когда хочу ей воспользоваться.
В жизни вообще нет никаких гарантий. Все рано или поздно сломается либо само по себе, либо потому что кто-то по глупости или намеренно сломает. Даже железная двутавровая балка рано или поздно либо проржавеет, либо лопнет от усталости металла, либо ее кто-то украдет на металлолом.
Контр-примеры можно найти к чему угодно в этой жизни. И любую практику можно довести до абсурда. Истина, как всегда, где-то посередине.
Что касается миграции, то я в свое время работал над достаточно большим проектом, который за 10 лет совершил миграции Subversion -> Mercurial -> Git (непонятно, зачем был нужен последний шаг, но не я принимал такие решения). Тем не менее, вся история осталась доступна, начиная с первого коммита.
Если переносить файл командой git mv, то ничего не потеряется. Если функцию переносить из файла в файл, то в той же IDEA можно достаточно легко отследить ее миграцию используя функцию "Annotate previous version."
Вообще, ничего идеального нет, но в общем и целом, если писать осмысленные коммиты, то это иногда сильно упрощает понимание кода.
Может быть есть мега-мозги, которые помнят каждую деталь, которую они сделали в своей жизни, я же даже возвращаясь к своему проекту спустя три-четыре месяца не всегда могу ответить на вопрос, зачем же здесь сделано именно так. Что уж говорить, когда смотрю на чужой код.
С хорошей историей нередко можно разобраться в том, почему было принято то или иное решение.
Я не говорил, что пишу коммиты именно так, как описано в статье. Я пишу осмысленные коммиты, как правило, это одна строка с таким описанием изменения, по которому можно понять, зачем оно было сделано, со ссылкой на соответствующий тикет в багтрекере. Напимер, Do not display QA Check button when evaluation hasn't been performed (#270).
Я не вижу смысла предоставлять какие-то пруфы, так как это не rocket science и требует, в общем-то, минимальных усилий от разработчика. Не сложнее, чем чистить зубы два раза в день, некий минимальный уровень гигиены.
У меня на GitHub только private-репозитории для проектов под NDA. За исключением пары pet projects и пары небольших клонов созданных для создания PR с исправлением какой-нибудь ерунды в open source библиотеках.
А что вы хотите увидеть? Пример моего плохого кода? Или наоборот, пример идеального?
Я идеально не пишу, но сообщения к коммитам стараюсь писать осмысленные, чтобы хотя бы мне через месяц было понятно, зачем я сделал то или иное изменение.
Мне для сложных случаев проще использовать командую строку с ack-grep или аналогом (silversearcher, да много их). Если поиска в Idea недостаточно, то в командной строке я могу быстро набросать любую возможную комбинацию из find, ack, xargs, grep.
Мне это как-то проще, чем целиться мышкой в десятки чекбоксов.
А для физических лиц есть? Я люблю путешествовать на мото в одиночку по безлюдным местам, и эта тема меня интересует. Пока нарыл только трекеры Spot и Garmin InReach. Spot дешевле, и им пользуется огромное количество путешественников.
Кстати, JetHabr, возможно вам Spot также подойдет — у них покрытие почти по всему земному шару.
Стоит тогда вспомнить, что тогда не-shared хостинги были очень редки и стоили в несколько раз (возможно, на порядок) дороже shared хостингов.
А Zope была мега-крутой штукой, просто космос, по сравнению со всем остальным, что тогда было. Но с определенными недостатками. Меня больше всего бесило редактирование TTW, которое в браузерах того времени просто не могло работать нормально. Потом появился ExternalEditor, но это было уже когда эпоха Zope начала клониться к закату.
Ну и ни один проект на Zope почти не взлетел, так как требовалась серьезная квалификация разработчиков. Особенно, когда пошли Plone и Zope 3. Документации толковой не было, книг тоже, все приходилось изучать по исходному коду.
Знакомый (не знаю, есть ли он на Хабре) когда-то сделал мощный портал на Zope 3, потом жаловался, что для поддержки и развития не удалось найти ни одного разработчика — слишком сложная архитектура.
Да что там говорить, до сих пор львиная доля сайтов делается на PHP и Javascript, и вовсе не потому, что эти языки имеют весомые преимущества. Скорее потому, что любой может осилив 5 строк введения начать лабать на этих языках сайты, пускай это спагетти-код, пускай там тоннами используются неинициализированные переменные, и т.д. Не требуется знать ничего: садись да пиши.
pysnmp — библиотека не из stdlib. Вполне возможно, что она просто неэффективно написана.
У меня в 4-х летнем ноутбуке есть разъем с поддержкой гарнитуры. Только мне пока не удалось найти гарнитуру, которая к нему бы подходила (специально не искал, но телефонная не работает — звук не пишется).
Я, к сожалению, очень мало что знаю об архитектуре современных процессоров. Но на Hacker News прочитал комментарий (без пруфов), что в Itanium эти атаки были бы невозможны.
К сожалению, укрупнение и монополизация приводят к некрасивым результатам. Если у нас остался один производитель процессоров, то в случае серьезной уязвимости, нам некуда деться.
Если нас забанил Google, то это для некоторых людей может быть почти тем же самым, что и быть забаненым в Интернет.
Не проще ли для поездов передавать энергию по проводам, как это делается с незапамятных времен? Я понимаю топливные элементы в авто — авто может заехать куда угодно. Но поезда то движутся всегда по одним и тем же дорогам, которые можно электрифицировать, и это наверняка проще и дешевле.
Жизнь показывает, что чем позже вкладываешься в пирамиду, тем выше шансы прогореть.
Нет, дело именно в том, что устройство не подключается. В панели Gnome оно отображается как сопряженное, на секунду подключается и тут же отключается.
Я планирую посмотреть как-нибудь, что при этом пишется в логи, просто сейчас на это совсем нет времени.
Но это просто из последнего. А так у меня вообще, весь опыт взаимодействия bluetooth устройств с Linux исключительно негативный. Все время что-нибудь не работает.
Впрочем, когда у меня была девушка, а у нее был ноутбук с Windows, там с BT тоже были вечные проблемы. Так что возможно дело в самой технологии Bluetooth, а не конкретных реализациях.
Почему нет? Вот даже в США, которых многие на Хабре считают образцом во всем, в US Air Force решили писать код сами. Конечно, не только они пишут, просто это первое что вспомнилось, так как об этом недавно писали на Hacker News.
Невозможно создать универсальный инструмент, подходящий для абсолютно всех ситуаций. Нельзя болгаркой и ремонтировать авто, и строить дома.
Если вы интересуетесь авто-мото темой, то наверняка заметили, что львиная доля трепотни об авто — это обсуждения наподобие: «Как жаль, что нет авто, с двигателем, который проезжает 1,000,000 км без капиталки, который отлично управляется на треке, в городе, и проезжает в болоте, да еще, чтобы стоил дешевле $20,000 и налоги на него были невысокие». Или в мото: «Хочу турэндуро с движком 1,5 л и 200 лошадей, чтобы и на треке гонять, и в выходные по лесу. И с запасом хода от 500 км. При этом быть легче 150 кг, легко рулиться, и быть невысоким».
Начиная с какого-то момента требования становятся противоречивыми. Можно увеличить мощность, но это увеличит вес и стоимость и снизит надежность. Можно снизить вес, но для этого придется использовать менее мощный мотор и более дорогие материалы (легкие сплавы вместо стали).
Выхода два: использовать несколько инструментов, каждый для своей задачи, или мириться с недостатками, при использовании не по назначению.
Если бы существовал идеальный инструмент для всех задач, то все бы на него перешли, и language holywars ушли бы в прошлое.
Справедливости ради, у Сбера неплохое приложение. Я работал с приложениями банков, которые были намного хуже. В том числе, зарубежные большие банки.
Ой, ну прям быть мелкой конторой — это серебряная пуля. Решает абсолютно все проблемы.
Если что, в мелких конторах еще больше нехватка разработчиков, и часто качество и безопасность приносится в жертву «business requirements».
Разработчик: «У нас здесь SQL injection в унаследованном коде, который мы купили у компании А»
Менеджер: «Твоя задача на сегодня починить форму Б в модуле С. Это важная задача для бизнеса. Через два месяца мы выкатим новую версию, тогда у тебя будет время, чтобы исправить эту injection и остальные баги».
Но естественно, через два месяца будет какой-то другой аврал, и все баги, дыры, и так далее копятся до бесконечности.
У меня вообще Bluetooth никогда не работал нормально. Просто вообще никогда. Разные устройства, разное железо, разные ядра, всегда все или не находится, или не сопрягается, или отваливается через 1 минуту.
Вот и сейчас у меня есть Bluetooth колонка. С телефоном на Android (который тот же Linux) она работает. А с Ubuntu 18.04 — нет. После первого сопряжения работает, но если выключить и включить колонку или ноутбук, то уже не работает. Приходится вручную удалять сопряжение и сопрягать заново каждый раз, когда хочу ей воспользоваться.
В жизни вообще нет никаких гарантий. Все рано или поздно сломается либо само по себе, либо потому что кто-то по глупости или намеренно сломает. Даже железная двутавровая балка рано или поздно либо проржавеет, либо лопнет от усталости металла, либо ее кто-то украдет на металлолом.
Контр-примеры можно найти к чему угодно в этой жизни. И любую практику можно довести до абсурда. Истина, как всегда, где-то посередине.
Что касается миграции, то я в свое время работал над достаточно большим проектом, который за 10 лет совершил миграции Subversion -> Mercurial -> Git (непонятно, зачем был нужен последний шаг, но не я принимал такие решения). Тем не менее, вся история осталась доступна, начиная с первого коммита.
Спасибо за интересный рассказ. Один момент непонятен: про заливание дизтоплива в карбюратор: дизели не используют карбюраторы.
Если переносить файл командой
git mv, то ничего не потеряется. Если функцию переносить из файла в файл, то в той же IDEA можно достаточно легко отследить ее миграцию используя функцию "Annotate previous version."Вообще, ничего идеального нет, но в общем и целом, если писать осмысленные коммиты, то это иногда сильно упрощает понимание кода.
Может быть есть мега-мозги, которые помнят каждую деталь, которую они сделали в своей жизни, я же даже возвращаясь к своему проекту спустя три-четыре месяца не всегда могу ответить на вопрос, зачем же здесь сделано именно так. Что уж говорить, когда смотрю на чужой код.
С хорошей историей нередко можно разобраться в том, почему было принято то или иное решение.
Я не говорил, что пишу коммиты именно так, как описано в статье. Я пишу осмысленные коммиты, как правило, это одна строка с таким описанием изменения, по которому можно понять, зачем оно было сделано, со ссылкой на соответствующий тикет в багтрекере. Напимер,
Do not display QA Check button when evaluation hasn't been performed (#270).Я не вижу смысла предоставлять какие-то пруфы, так как это не rocket science и требует, в общем-то, минимальных усилий от разработчика. Не сложнее, чем чистить зубы два раза в день, некий минимальный уровень гигиены.
У меня на GitHub только private-репозитории для проектов под NDA. За исключением пары pet projects и пары небольших клонов созданных для создания PR с исправлением какой-нибудь ерунды в open source библиотеках.
А что вы хотите увидеть? Пример моего плохого кода? Или наоборот, пример идеального?
Я идеально не пишу, но сообщения к коммитам стараюсь писать осмысленные, чтобы хотя бы мне через месяц было понятно, зачем я сделал то или иное изменение.
Да, я тоже считаю, что нужна общая дисциплина, в которой и хорошие комментарии надо писать не только к коду, но и к коммитам тоже.
Системы контроля версий существуют в том числе и потому, что история изменений тоже имеет ценность.