Или вот например, банк имеет право закрыть счет юр.лицу или ИП вообще без объяснения причин и каких-либо компенсаций — просто из страха, что до него докопаются проверяющие органы. И ничего, работаем, выстраиваем человеческие отношения там, где законы плохо справляются с регулированием.
Ну правда, странная статья. Вывод строится на двух посылах:
суммарные долги юрлиц и ИП растут. Да, но какая часть в этом графике — долги именно ИП? Я не знаю ответа, но могу предположить, что ИП, как финансово незащищенные и менее прозрачные, закредитованы куда меньше.
Робокассу закрыли. Тот факт, что их пугнули напрямую из ЦБ, конечно, печален, но как закрыли, так и открыли. Плюс желающие просто переехали на другие сервисы.
Отсюда вовсе не следует вывод, что с ИП всё плохо и нужно перебираться на ОАО или готовить трактор.
Да, государство меняет правила игры на ходу. Да, интерпретация закона конкретным чиновником куда важнее, чем то, что в нем написано, во всех гос структурах — от местной налоговой до ЦБ. Но хочешь жить — умей вертеться, и конкретно ИП тут ни при чем :-)
Наверное, речь идет о С++ и документации к API? Я пишу на Java и там нет такой проблемы — документация к методу находится в исходниках непосредственно над методом и практически ко всем библиотекам есть исходники, которые автоматически подцепляются к проекту. Если же речь идет о крупном закрытом API — то я предпочитаю документацию, оформленную одним документом в html или pdf и ищу по ctrl+f. Если такой возможности нет — то да, только гугль. Почти всегда он ищет лучше, чем специализированные "поиски по онлайн документации".
Что такое "услуга"? Я думал, что канал — это и есть услуга. Т.е. сам факт существования канала означает, что кто-то предоставляет услугу.
Возьмем, к примеру, канал жесткого диска. Как некой задаче прочитать данные с диска?
она формирует подзадачу и передает её каналу жесткого диска с параметрами (operation=READ, sector=123456)
канал (?) или другая задача прикрепленная к каналу? (как тогда она узнает о п.1?) отправляет запрос на контроллер жесткого диска с просьбой прочитать данные в память (в память канала? в память вызывающей таски?) и добавляет таску в канал, владеющий прерываниями.
когда чтение завершено, вызывается прерывание, которое приводит к вызову таски из канала прерываний, которая вызывает таску из п.1, сигнализируя вызывающему коду об окончании операции.
Так?
С позиции опытного разработчика:
Гуглить что?
Чаще всего я гуглю тексты ошибок и куски стектрейсов
Затем — тёмные или подзабытые места фреймворков типа "hibernate declare composite key". Если мне нужно начать использовать новый фреймворк, я предпочту потратить день и прочитать официальную документацию.
И никогда — чужой код. Чужой код при решении проблем нужен только для того, чтобы изучить те API, которыми он пользуется для решения проблемы.
Исключение — это реализация достаточно сложных алгоритмов типа BCrypt, но и там не стоит брать первый попавшийся кусок.
Вкратце: гуглить надо прежде всего чужой опыт и чужие впечатления. Знания лучше по-возможности получать из документации, а код — писать самому или брать известные библиотеки.
"Тебе подняли ЗП, теперь ты обязан не возникать по поводу её роста n лет" — это обыкновенная манипуляция над работниками, которые плохо понимают, что такое бизнес-риски.
"на сколько тебе поднять зп, чтобы ты не ушел" и "на сколько тебе поднять зп, чтобы ты покрыл риск того, что твоя стоимость значительно вырастет, а ты обязался работать за фиксированную зп ближайшие 2 года" — это совершенно разные вещи.
Если я правильно понял, канал — это менеджер задач + некая разделяемая память. Если я хочу прочитать из канала, я добавляю в него задачу, передавая параметрами то, что хочу прочитать. Когда данные будут готовы, канал их запишет в разделяемую память канала и вызовет мою задачу. Если я хочу записать в канал, то аналогично — я добавляю задачу, которая пишет в разделяемую память канала. Синхронизация не нужна, т.к. канал использует одно ядро процессора (через соответствующий канал процессора).
Если так, то…
Разве передача всех данных в канал через разделяемую память канала — это не излишество? У пишущей задачи, как правило, уже есть собственный буфер с данными и его придется копировать в память канала.
Зачем нужно различать экспортеров и импортеров?
export/import — нужен для маппинга канала в userspace и для удаленных(remote) каналов? В принципе, никто не мешает работать напрямую с исходным каналом, так?
Зачем каждому каналу собственный менеджер памяти?
Вообще не знаю как насчет операционных систем, но эта идея выглядит интересной для построения сетевых приложений…
При работе без посредника полезно показывать результат через shared desktop в скайпе, ну или дать ему самому потыкать через teamviewer. Потом просить деньги вперед, т.к. у вас как у исполнителя нет мотивации не отправлять уже сделанную работу.
Я считаю, что основная причина не нанимать джуниоров — это тот факт, что качество проекта получается как среднее арифметическое навыков всех его участников, несмотря на всё лидерство тимлида. Так что джунов берут:
компании, ориентированные на минимальную стоимость в ущерб качеству — т.н. заказная разработка
достаточно крупные компании, где всегда есть низкоквалифицированная работа без особых требований к качеству
крупные компании, которые могут позволить себе отобрать многообещающих студентов, вырастить их и удержать их. У Яндекса и Дойчебанка, например, такие программы есть.
Еще важный момент — пользователи b2b сайтов, как правило, проходят обучение или хотя бы читают инструкцию. И волнует их не интуитивность интерфейса, а корректная работа клавиши Tab и наличие горячих клавиш.
Первая картинка хорошая — наконец-то внятное объяснение, что такое "программрировать на HTML".
А вообще перечисленные качества — работать для людей, аппетит к знаниям, умение разобраться в проблеме, немного безумия и настойчивость — это 100% надежный рецепт успеха в любой сфере. Так может если есть желание к 40 бросить всё и подасться в высооплачиваемые программисты, начать не с изучения HTML, а с развития этих качеств?
А правильно логгировать — отдельное искусство. Для высоконагруженных серверов обычно применяют вот такие практики:
Успешный запрос должен логгировать аккуратно выверенный минимум информации. Если объем реально большой, то логгировать нужно каждый n-ный запрос. Тогда в случае массовых ошибок в логах гарантированно окажутся нужные данные
При высоких требованиях к latency используют не текстовые, а двоичные логи, опционально еще и сжимая их перед записью
В наше время сеть куда быстрее диска, так что если нет жестких требований к целостности логов, можно логгировать их в сеть на специализированный сервис, типа Kafka
Должна быть возможность включать debug-логгирование временно для всего приложения и для отдельных запросов, например, указывая специальный флаг в теле запроса
Полезные метрики, типа кол-ва запросов в секунду, не считаются через анализ логов, а собираются и аггрегируются самим приложением и пишутся раз в n секунд.
логи должны содержать requestId, уникальный для каждого запроса, желательно в пределах всей системы, а не только одного приложения.
для бизнес-аналитики очень полезно иметь структурированные логи, например, в виде json, где назначение каждого поля описано в отдельном документе, и названия полей консистентны для всей системы.
Мы начинали со swagger, но в итоге от него отказались — его спецификация до сих пор реализована только частично и качество инструментария, мягко говоря, не очень хорошее.
Результат выглядит примерно так:
summary("API call summary")
description("long, possibly multiline description of this API call"
pathParam[String]("db", "current database name")
pathParam[String]("coll", "current collection")
queryParam[Int]("offset", "current paging offset")
queryParam[Int]("limit", "number of elements per page")
produces[MyResponseTO]("application/javascript")
get("/db/{db}/coll/{coll}", (db, coll) => { ..... Future successful response })
Насчет документации — мы пошли другим путем. Документация содержится непосредственно в коде, реализующем методы REST API. У нас Scala, это несколько улучшает внешний вид метаданных и уменьшает избыточность. При старте приложения по этим метаданным генерится HTML и вывешивается на /api в каждом микросервисе. Таким образом:
— документация всегда актуальна
— документация всегда под рукой (если ты можешь обращаться к микросервису, ты можешь сделать GET /api в браузере)
— и, в результате, мнгновенный ответ на вопросы типа «а что вообще умеет эта штука, которую мы два года назад написали?» и «подзабыл название поля в API, как быстро посмотреть»
Вдруг кто еще не видел
Или вот например, банк имеет право закрыть счет юр.лицу или ИП вообще без объяснения причин и каких-либо компенсаций — просто из страха, что до него докопаются проверяющие органы. И ничего, работаем, выстраиваем человеческие отношения там, где законы плохо справляются с регулированием.
Ну правда, странная статья. Вывод строится на двух посылах:
Отсюда вовсе не следует вывод, что с ИП всё плохо и нужно перебираться на ОАО или готовить трактор.
Да, государство меняет правила игры на ходу. Да, интерпретация закона конкретным чиновником куда важнее, чем то, что в нем написано, во всех гос структурах — от местной налоговой до ЦБ. Но хочешь жить — умей вертеться, и конкретно ИП тут ни при чем :-)
Наверное, речь идет о С++ и документации к API? Я пишу на Java и там нет такой проблемы — документация к методу находится в исходниках непосредственно над методом и практически ко всем библиотекам есть исходники, которые автоматически подцепляются к проекту. Если же речь идет о крупном закрытом API — то я предпочитаю документацию, оформленную одним документом в html или pdf и ищу по ctrl+f. Если такой возможности нет — то да, только гугль. Почти всегда он ищет лучше, чем специализированные "поиски по онлайн документации".
Вот, почитайте: https://support.google.com/websearch/answer/2466433?hl=ru
Что такое "услуга"? Я думал, что канал — это и есть услуга. Т.е. сам факт существования канала означает, что кто-то предоставляет услугу.
Возьмем, к примеру, канал жесткого диска. Как некой задаче прочитать данные с диска?
Так?
С позиции опытного разработчика:
Гуглить что?
Чаще всего я гуглю тексты ошибок и куски стектрейсов
Затем — тёмные или подзабытые места фреймворков типа "hibernate declare composite key". Если мне нужно начать использовать новый фреймворк, я предпочту потратить день и прочитать официальную документацию.
И никогда — чужой код. Чужой код при решении проблем нужен только для того, чтобы изучить те API, которыми он пользуется для решения проблемы.
Исключение — это реализация достаточно сложных алгоритмов типа BCrypt, но и там не стоит брать первый попавшийся кусок.
Вкратце: гуглить надо прежде всего чужой опыт и чужие впечатления. Знания лучше по-возможности получать из документации, а код — писать самому или брать известные библиотеки.
Ну, как автор единственного комментария по теме, я бы хотел получить более развернутый ответ :-)
"Тебе подняли ЗП, теперь ты обязан не возникать по поводу её роста n лет" — это обыкновенная манипуляция над работниками, которые плохо понимают, что такое бизнес-риски.
"на сколько тебе поднять зп, чтобы ты не ушел" и "на сколько тебе поднять зп, чтобы ты покрыл риск того, что твоя стоимость значительно вырастет, а ты обязался работать за фиксированную зп ближайшие 2 года" — это совершенно разные вещи.
Если я правильно понял, канал — это менеджер задач + некая разделяемая память. Если я хочу прочитать из канала, я добавляю в него задачу, передавая параметрами то, что хочу прочитать. Когда данные будут готовы, канал их запишет в разделяемую память канала и вызовет мою задачу. Если я хочу записать в канал, то аналогично — я добавляю задачу, которая пишет в разделяемую память канала. Синхронизация не нужна, т.к. канал использует одно ядро процессора (через соответствующий канал процессора).
Если так, то…
Разве передача всех данных в канал через разделяемую память канала — это не излишество? У пишущей задачи, как правило, уже есть собственный буфер с данными и его придется копировать в память канала.
Зачем нужно различать экспортеров и импортеров?
export/import — нужен для маппинга канала в userspace и для удаленных(remote) каналов? В принципе, никто не мешает работать напрямую с исходным каналом, так?
Зачем каждому каналу собственный менеджер памяти?
Вообще не знаю как насчет операционных систем, но эта идея выглядит интересной для построения сетевых приложений…
разработка не ограничивается веб-приложениями, да и бесплатная верстка на дороге не валяется.
При работе без посредника полезно показывать результат через shared desktop в скайпе, ну или дать ему самому потыкать через teamviewer. Потом просить деньги вперед, т.к. у вас как у исполнителя нет мотивации не отправлять уже сделанную работу.
Я считаю, что основная причина не нанимать джуниоров — это тот факт, что качество проекта получается как среднее арифметическое навыков всех его участников, несмотря на всё лидерство тимлида. Так что джунов берут:
За 10 лет работы, мне ВСЕГДА поднимали зарплату только таким образом.
Еще важный момент — пользователи b2b сайтов, как правило, проходят обучение или хотя бы читают инструкцию. И волнует их не интуитивность интерфейса, а корректная работа клавиши Tab и наличие горячих клавиш.
Первая картинка хорошая — наконец-то внятное объяснение, что такое "программрировать на HTML".
А вообще перечисленные качества — работать для людей, аппетит к знаниям, умение разобраться в проблеме, немного безумия и настойчивость — это 100% надежный рецепт успеха в любой сфере. Так может если есть желание к 40 бросить всё и подасться в высооплачиваемые программисты, начать не с изучения HTML, а с развития этих качеств?
А правильно логгировать — отдельное искусство. Для высоконагруженных серверов обычно применяют вот такие практики:
Мы начинали со swagger, но в итоге от него отказались — его спецификация до сих пор реализована только частично и качество инструментария, мягко говоря, не очень хорошее.
Результат выглядит примерно так:
— документация всегда актуальна
— документация всегда под рукой (если ты можешь обращаться к микросервису, ты можешь сделать GET /api в браузере)
— и, в результате, мнгновенный ответ на вопросы типа «а что вообще умеет эта штука, которую мы два года назад написали?» и «подзабыл название поля в API, как быстро посмотреть»