то да, что стало приятным сюрпризом. Умеет, к сожалению, не всё (сложные архивные операции, когда надо переименовать одинаково названные файлы, лежащие в том же самом каталоге - тут у Far2l сложности), но почти все остальное работает прям как родное. И очень быстро, притом.
Оно и работало быстро. В svn создание ветки было очень быстрой и дешевой операцией, что в те времена было на острие технического прогресса, потому что так умели тогда далеко не все системы контроля версий, даже платные. Это ускоряло и облегчало разработку просто в разы. Репозиторий хранился в централизованной БД на сервере, и для работы требовалась связь с ним - это да, но при работе над маленькими и средними проектами в рамках одной компании это абсолютно не мешало. Хотя сверхогромные проекты, такие как Windows NT, svn скорее всего не потянул бы.
Мое предположение, что это пошло в массы из-за того, что лет 25 назад в тренде была разработка на технологиях Microsoft, а в терминологии Win32 API числовой дескриптор многих объектов ОС Windows (окна, оконного контрола (извините, управляющего элемента), например кнопки, и т.п.) назывался HANDLE, то есть, дословно "ручка". И, чтобы что-нибудь с этим элементом сделать (ну, перекрасить в красный цвет), надо для начала этот дескриптор (handle) откуда-то получить. Возможно, оно потом как-то перекочевало на API endpoints и вот это всё.
Ууу, какие преданья старины глубокой. Впрочем, работа с MS SQL (правда, помню только с версии 7.0, так я ж и помладше буду) оставила только положительные впечатления - очень стабильная, устойчивая, хорошо спроектированная, масштабируемая СУБД, при этом там имелся и весь нужный тулинг - от bcp для импорта какого угодно количества CSV-файлов в базу, до Enterprise manager, где можно было с помощью графического интерфейса перетащить первичный ключ на внешний и оно создавало констрэйнт типа FOREIGN KEY (что, как я представляю сейчас, скорее навредило в долгосрочной перспективе). Transact SQL был вполне себе на уровне, работал очень быстро, а то, что оно понимало различие между UNION и UNION ALL прямо на уровне движка, позволило мне еще тогда спроектировать хоть и примитивное, но работающее "партиционирование". В общем, уж не знаю, сколько там в этой инженерии было от Sybase (скорее всего, ядро и прочее низкоуровневое), а сколько от Microsoft (скорее всего, тулинг, GUI-инструменты и маркетинг), но софт был очень впечатляющий для своего времени, да и сейчас вроде еще в энтерпрайзах вполне продолжает работать.
Рассказали бы, как вы открывали первый в мире магазин "Пятерочка" на перекрестке Прибрежной и Караваевской в 1999 году в Питере, и как оно выросло аж в X5 Retail Group, вот это была бы история!
Там как раз клавиша CapsLock превращается в клавишу РУС/ЛАТ, а светодиодная индикация к ней предусмотрена штатно. Ну и можно программу-индикатор состояния CapsLock добавить, которая будет в трее ее состояние показывать, чтоб каждый раз взгляд на клавиатурный светодиод не переводить.
Нда, и если идти всё-таки работать в Google, то там начальниками у тебя будут люди, прошедшие через такой опыт. Это не плохо и не хорошо, но это несколько напоминает армию (где я не был), и, наверное, дисциплина там соответствует.
Да, формально вы правы, если использовать СБПэй, то необходимости в интернет-банкинге конкретного банка не будет. То есть жесткой необходимости привязываться к сервису интернет-банкинга нет. Но зависит от конкретной реализации, то есть до СБП можно добраться и через интернет-банкинг (который выступает как прокси, плюс обеспечивает авторизацию клиента, и т.п.), и такие решения встречаются.
На кассах, кстати, по СБП платить не очень удобно, потому что платеж завязан на банковское приложение, а оно - на интернет-банкинг того конкретного банка, приложение которого используется для оплаты. И если в этот момент он тормозит или глючит, то запросто можно получить ситуацию, когда один человек стоит перед терминалом, у него не проходит платеж, и очередь сзади уже собирается его линчевать.
При традиционной оплате картами интернет-банкинг напрямую не требуется, там задействуется только обмен информацией с процессинговыми центрами, а у них стабильность работы выше, и вероятность, что платеж зависнет - меньше.
+1, всего один или два раза спрашивал там не самый сложный вопрос (который, однако, не хватило понимания, как загуглить), и отношение отвечающих было не просто корректное, а прямо доброжелательное. А потом как-то научился понимать, какие слова вбивать в форму поиска Гугла, чтобы с большой вероятностью получать правильный ответ, который, обычно, как раз на StackOverflow и отвечен. Но, надо, во-первых, использовать английский язык (для русского эти алгоритмы у них работают, но гораздо хуже), ну и быть морально готовому, что нужный ответ может оказаться не по первой ссылке, а по второй, третьей, а то и на следующей странице.
Продолжайте в том же духе, и, если не остановитесь, то, перечитав эту статью лет через 10, вы найдете в ней достаточно моментов, которые вам захочется сделать по-другому. Искренне желаю успеха на этом тернистом пути. А пока просто акцентирую внимание на моменте, который мне показался самым спорным в вашем решении - вы исходите из предположения, что между первым тэгом <description> и последним тэгом </description> всегда будет, условно говоря, "чистый текст с описанием" (то же относится к вашей обработке тэгов <body> и </body>). В частных случаях это может быть так, но обычно в xml-подобных форматах допускается произвольная вложенность тэгов, и на ней наивный алгоритм сразу даст сбой.
Хехе, вы ответили автору этой программы ) Воистину, тесен мир.
Я уже сейчас не помню в подробностях, как там было что написано, но ощущение было, что все довольно аккуратно (кастомная реализация HTTP и FTP над сокетами в Windows). Когда мне тоже пришлось реализовывать подмножество HTTP на уровне сокетов (потому что все "промышленные" и "стандартные" библиотеки так и не удалось заставить работать нормально, хотя мы всей командой два месяца пытались), то те знания всплыли и пригодились.
то да, что стало приятным сюрпризом. Умеет, к сожалению, не всё (сложные архивные операции, когда надо переименовать одинаково названные файлы, лежащие в том же самом каталоге - тут у Far2l сложности), но почти все остальное работает прям как родное. И очень быстро, притом.
Оно и работало быстро. В svn создание ветки было очень быстрой и дешевой операцией, что в те времена было на острие технического прогресса, потому что так умели тогда далеко не все системы контроля версий, даже платные. Это ускоряло и облегчало разработку просто в разы. Репозиторий хранился в централизованной БД на сервере, и для работы требовалась связь с ним - это да, но при работе над маленькими и средними проектами в рамках одной компании это абсолютно не мешало. Хотя сверхогромные проекты, такие как Windows NT, svn скорее всего не потянул бы.
кстати, правда, где? что-то очень давно его не видно не слышно
это да. я не настоящий функциональщик, но иногда посматриваю в ту сторону. Вот на страничке Control.Lens.Operators перечисляются эти операторы:
123 оператора. Это точно надо их столько, чтобы программировать? Вот и я задаюсь этим риторическим вопросом.
Hidden text
(#%%=)
(#%%~)
(#%=)
(#%~)
(#)
(#=)
(#~)
(%%=)
(%%@=)
(%%@~)
(%%~)
(%=)
(%@=)
(%@~)
(%~)
(&&=)
(&&~)
(&)
(&~)
(=) (~)
(=) (~)
(+=)
(+~)
(-=)
(-~)
(...)
(.=)
(.>)
(.@=)
(.@~)
(.~)
(//=)
(//~)
(<#%=)
(<#%~)
(<#=)
(<#~)
(<%=)
(<%@=)
(<%@~)
(<%~)
(<&&=)
(<&&~)
(<&>)
(<=) (<~)
(<=) (<~)
(<+=)
(<+~)
(<-=)
(<-~)
(<.)
(<.=)
(<.>)
(<.~)
(<//=)
(<//~)
(<<%=)
(<<%@=)
(<<%@~)
(<<%~)
(<<&&=)
(<<&&~)
(<<=) (<<~)
(<<=) (<<~)
(<<+=)
(<<+~)
(<<-=)
(<<-~)
(<<.=)
(<<.~)
(<<//=)
(<<//~)
(<<<>=)
(<<<>~)
(<<>=)
(<<>~)
(<<?=)
(<<?~)
(<<^=)
(<<^^=)
(<<^^~)
(<<^~)
(<<||=)
(<<||~)
(<<~)
(<>)
(<>=)
(<>~)
(<?=)
(<?~)
(<^=)
(<^^=)
(<^^~)
(<^~)
(<|)
(<||=)
(<||~)
(<~)
(?=)
(??)
(?~)
(^#)
(^.)
(^..)
(^=)
(^?!)
(^?)
(^@.)
(^@..)
(^@?!)
(^@?)
(^^=)
(^^~)
(^~)
(|>)
(||=)
(||~)
Мое предположение, что это пошло в массы из-за того, что лет 25 назад в тренде была разработка на технологиях Microsoft, а в терминологии Win32 API числовой дескриптор многих объектов ОС Windows (окна, оконного контрола (извините, управляющего элемента), например кнопки, и т.п.) назывался HANDLE, то есть, дословно "ручка". И, чтобы что-нибудь с этим элементом сделать (ну, перекрасить в красный цвет), надо для начала этот дескриптор (handle) откуда-то получить. Возможно, оно потом как-то перекочевало на API endpoints и вот это всё.
Ууу, какие преданья старины глубокой. Впрочем, работа с MS SQL (правда, помню только с версии 7.0, так я ж и помладше буду) оставила только положительные впечатления - очень стабильная, устойчивая, хорошо спроектированная, масштабируемая СУБД, при этом там имелся и весь нужный тулинг - от bcp для импорта какого угодно количества CSV-файлов в базу, до Enterprise manager, где можно было с помощью графического интерфейса перетащить первичный ключ на внешний и оно создавало констрэйнт типа FOREIGN KEY (что, как я представляю сейчас, скорее навредило в долгосрочной перспективе). Transact SQL был вполне себе на уровне, работал очень быстро, а то, что оно понимало различие между UNION и UNION ALL прямо на уровне движка, позволило мне еще тогда спроектировать хоть и примитивное, но работающее "партиционирование". В общем, уж не знаю, сколько там в этой инженерии было от Sybase (скорее всего, ядро и прочее низкоуровневое), а сколько от Microsoft (скорее всего, тулинг, GUI-инструменты и маркетинг), но софт был очень впечатляющий для своего времени, да и сейчас вроде еще в энтерпрайзах вполне продолжает работать.
Рассказали бы, как вы открывали первый в мире магазин "Пятерочка" на перекрестке Прибрежной и Караваевской в 1999 году в Питере, и как оно выросло аж в X5 Retail Group, вот это была бы история!
Господи, спаси и помилуй
нда, еще 20 лет хреначить, получается...
Для меня конец мучений наступил тогда, когда я везде внедрил решение из статьи:
https://habr.com/ru/articles/301882/
Там как раз клавиша CapsLock превращается в клавишу РУС/ЛАТ, а светодиодная индикация к ней предусмотрена штатно. Ну и можно программу-индикатор состояния CapsLock добавить, которая будет в трее ее состояние показывать, чтоб каждый раз взгляд на клавиатурный светодиод не переводить.
Эх, и влепил бы статье минус, да комментов жалко )
Нда, и если идти всё-таки работать в Google, то там начальниками у тебя будут люди, прошедшие через такой опыт. Это не плохо и не хорошо, но это несколько напоминает армию (где я не был), и, наверное, дисциплина там соответствует.
Да, формально вы правы, если использовать СБПэй, то необходимости в интернет-банкинге конкретного банка не будет. То есть жесткой необходимости привязываться к сервису интернет-банкинга нет. Но зависит от конкретной реализации, то есть до СБП можно добраться и через интернет-банкинг (который выступает как прокси, плюс обеспечивает авторизацию клиента, и т.п.), и такие решения встречаются.
На кассах, кстати, по СБП платить не очень удобно, потому что платеж завязан на банковское приложение, а оно - на интернет-банкинг того конкретного банка, приложение которого используется для оплаты. И если в этот момент он тормозит или глючит, то запросто можно получить ситуацию, когда один человек стоит перед терминалом, у него не проходит платеж, и очередь сзади уже собирается его линчевать.
При традиционной оплате картами интернет-банкинг напрямую не требуется, там задействуется только обмен информацией с процессинговыми центрами, а у них стабильность работы выше, и вероятность, что платеж зависнет - меньше.
+1, всего один или два раза спрашивал там не самый сложный вопрос (который, однако, не хватило понимания, как загуглить), и отношение отвечающих было не просто корректное, а прямо доброжелательное. А потом как-то научился понимать, какие слова вбивать в форму поиска Гугла, чтобы с большой вероятностью получать правильный ответ, который, обычно, как раз на StackOverflow и отвечен. Но, надо, во-первых, использовать английский язык (для русского эти алгоритмы у них работают, но гораздо хуже), ну и быть морально готовому, что нужный ответ может оказаться не по первой ссылке, а по второй, третьей, а то и на следующей странице.
Попробуйте почитать книжку Секацкого "Моги и их могущества". Вам может понравиться.
Продолжайте в том же духе, и, если не остановитесь, то, перечитав эту статью лет через 10, вы найдете в ней достаточно моментов, которые вам захочется сделать по-другому. Искренне желаю успеха на этом тернистом пути. А пока просто акцентирую внимание на моменте, который мне показался самым спорным в вашем решении - вы исходите из предположения, что между первым тэгом <description> и последним тэгом </description> всегда будет, условно говоря, "чистый текст с описанием" (то же относится к вашей обработке тэгов <body> и </body>). В частных случаях это может быть так, но обычно в xml-подобных форматах допускается произвольная вложенность тэгов, и на ней наивный алгоритм сразу даст сбой.
абстрактную
Хехе, вы ответили автору этой программы ) Воистину, тесен мир.
Я уже сейчас не помню в подробностях, как там было что написано, но ощущение было, что все довольно аккуратно (кастомная реализация HTTP и FTP над сокетами в Windows). Когда мне тоже пришлось реализовывать подмножество HTTP на уровне сокетов (потому что все "промышленные" и "стандартные" библиотеки так и не удалось заставить работать нормально, хотя мы всей командой два месяца пытались), то те знания всплыли и пригодились.