• Конференцию PHP Central Europe отменили из-за того, что среди выступающих не оказалось женщин
    0
    Это верно, девушки меньше идут в ИТ, но самое интересное — это узнать почему они не идут. Возможно, реклама этих специальностей и создание имиджа работы не только для красноглазых привлекли бы в эту сферу больше девушек. Это просто предположение, но я скорее о том, что мало отметить небольшой приток девушек в ИТ, но важно понять почему так.
  • Конференцию PHP Central Europe отменили из-за того, что среди выступающих не оказалось женщин
    0
    Мужчины и женщины конечно разные, с этим вряд-ли кто-то будет спорить. Но вот на счёт генов — это вопрос. Можете привести конкретное исследование, где написано, что это генетическая гендерная особенность, а не сложившийся стереотип, который навязывается нам обществом и родителями?
  • Функциональное программирование: дурацкая игрушка, которая убивает производительность труда. Часть 1
    0
    Так нетипизированный язык же, в том же котлине будет очевидно:
    fun main() {
        val fruitRepository = FruitRepository(
                Fruit(type = "apple", price = 1.99.toBigDecimal()),
                Fruit(type = "orange", price = 2.99.toBigDecimal()),
                Fruit(type = "grape", price = 44.95.toBigDecimal())
        )
    
        val price = fruitRepository.findFruitPriceByType("apple")
    
        println(price ?: "priceless")
    }
    
    data class Fruit(val type: String, val price: BigDecimal)
    
    class FruitRepository(vararg fruits: Fruit) {
    
        private val index = fruits.map { it.type to it }.toMap()
    
        fun findFruitByType(type: String): Fruit? = index[type]
    
        fun findFruitPriceByType(type: String): BigDecimal? = findFruitByType(type)?.price
    }
    
  • Не морочьте мне голову со своим функциональным программированием
    0
    [deleted]
  • Аудио через Bluetooth: максимально подробно о профилях, кодеках и устройствах
    0
    В итоге приходится использовать a2dp+мирофон ноута, потому что качество звука hsp слишком низкое. Патч для линукса — это интересное решение, но так с ходу не могу найти в гугле куда смотреть, посоветуете? Я правильно понял, что только FastStream позволяет решить этот задачу?
  • Аудио через Bluetooth: максимально подробно о профилях, кодеках и устройствах
    0
    получается, что сейчас никак нельзя и звук приличный иметь в наушниках и с микрофона звук снимать? и это ограничение на текущем стеке не обходится?
  • 10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик
    0
    Тогда возможно он должен быть не потомком, а экземпляром прямоугольника?
  • 10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик
    0
    Да, почему-то очень любят использовать связь прямоугольник-квардрат как иллюстрацию наследования, хотя это очень плохой пример и (подумав) такой код никогда в реальной жизни не напишешь. Мало того, что очень сложно выбрать, кто от кого наследуется, так еще и сразу начинают лезть несоответствия вроде того, что описал Frintezza93. Из за этого обычно не рекомендуют наследоваться от реализаций, но только от специально подготовленных астрактных классов или еще лучше реализовывать интерфейсы типа Figure с метдами вроде area() и дргуих.
  • Почему язык Go плох для НЕумных программистов
    +2
    Создается впечатление, что го располагает не только к тому, чтобы набирать неопытных разработчиков, но и неопытных авторов статей.
  • Функциональная обработка ошибок в Kotlin с помощью Arrow
    0
    если для каждого элемента важно значение или исключение, то это может быть удобно, да, как например это сделано в CompletableFuture. Но там это немного более уместно, потому что предполагает выполнение какого-то кода, который может свалиться. В концепции мэпа больше предполагается, что этот код будет падать только если совсем. Если код для каждого элемента может падать, то чаще для этих методов будет полезнее что-то вроде:
    inline fun <R> tryOrNull(block: () -> R?): R? = try {
        block()
    } catch (e: Exception) {
        null
    }
    
    fun aaa() {
        listOf(1, 2, 3).mapNotNull { tryOrNull { it / 0 } }
    }
    
  • Функциональная обработка ошибок в Kotlin с помощью Arrow
    0
    Нет, не тоже самое. Вы просто проглотили исключение. В Try же exception есть и в конце статьи написано как оно может быть обработано.
    ну да, если его надо обработать выше, надо просто этот же код написать выше, в чем тут проблема-то? и `try` надо только в одном месте написать.
    цепочку из монад с дальнейшей обработкой

    вызов метдов с `try-catch` это разве не цепочка с обработкой? в чем профит-то?
    Усложнение всё-таки должно быть чем-то оправдано, того, что я увидел в статье явно не хватает, чтобы взять это в использование в каких-то реальных кейзах, которые я использую. Я использую цепочки обработки для коллекций, например, там понятно, что мы получаем, декларативность, скрываем не относящийся к происходящему и повторяющийся код, а тут что? Заменили один механизм из коробки на другой из библиотеки, при этом декларативности особенной или переиспользования или понятности не получили, только усложнение и дополнительные зависимости.
  • Функциональная обработка ошибок в Kotlin с помощью Arrow
    +3
    Честно говоря, совершенно не убедительно. Профита не видно. Какой смысл оборачивать в Try всё подряд, если тоже самое делает обычный try-catch и поддержка nullability, типа
    fun makeRequest(request: String): List<Any>? = try {
        listOf()
    } catch (e: Exception) {
        null
    }
    
    fun main(args: Array<String>) {
        makeRequest("body")?.let { 
            it.map { it.toString() } 
        } ?: emptyList()
    }
    

    тоже самое, только из коробки, без доп-оберток и матчинг эксепшена по типу
  • Безликий код убьет программирование, и ничего мы с этим не сделаем
    +2
    Простота — это красота.

    Это абсолютно верно. Проблема начинается, когда упрощение работает против выразительности и безопасности. К тому же язык программирования чем-то схож с языком естественным, на нем тоже человек выражает какие-то свои мысли. И если тебе всё время нужно говорить про «снег», то хотя бы одно слово для этого нужно вместо «то, что холодное, белое и падает с неба». Это я к тому, что упрощение хорошо только до некоторого предела, гоу на мой взгляд эту грань перешел.
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    я это все к тому, что намного интереснее было бы посмотреть на транслятор, чем на парсер
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    мы ведь тут говорим и запуске шейдеров, а не о скриптовании
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    Я ведь и не предлагаю забывать. для разработки можно сделать режим разработчика, который используя тот же код может отслеживать и перекомпилировать на лету, для продакшена же это совершенно нужный инструмент, который добавляет сложности этой логике и вероятных ошибок
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    Я правильно понял, что посмотреть можно только на парсер, транслятор закрыт? Что же касается обсуждаемого вопроса: мне кажется, что тащить компилятор в продакшен рантайм занятие достаточно бессмысленное, ничто не мешает скомпилировать заранее, а для разработки можно и размер увеличить и подождать немного один раз.
  • Разработчик! Прекрати считать себя недостаточно хорошим специалистом, это неправда
    0
    чиф архитектом в кроссовере называют сеньоров, так что речь как раз о них
  • Разработчик! Прекрати считать себя недостаточно хорошим специалистом, это неправда
    0
    Было бы ради любопытства интересно взглянуть на вакансию в дефолтсити, где бы предлагали $100к в год сеньору.
  • Как это сделано: пишем «Сапера» за 4 минуты
    +4
    Хотя за 4 минуты такое конечно не напишешь, но качество кода очень похоже на то, что пытались написать именно за 4.
  • О языке Kotlin для Java-программистов
    +1
    Надо было этот коммент написать в 2022 на юбилей поста.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    0
    Конечно есть и «сочнее», но мы-то говорим примерно об одной позиции, которая попадает в мою компетенцию.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    0
    так и выдаваться заведомо ложная

    Вся информация предоставляемая мной в налоговую как ИП абсолютно законна и соответствует законодательству. Я декларирую все свои доходы, плачу с них налоги, тоже с пенсионными отчислениям и соц. платежами. Если суд вдруг решит, что эти отношения являются по сути трудовыми (что к слову не очевидно совершенно, потому что некоторые признаки очевидны, другие — совсем нет), то ответственность за не оформление трудовых отношений должным образом несет работодатель. Так что я лучше оставлю решение этих вопросов кроссоверу. Но опять же — было бы неплохо, если бы кроссовер прокомментировал эти нюансы официально.
    Тем не менее прямо здесь комментаторы делят заявленный годовой рейт на 12 и сравнивают с белой зарплатой нетто

    Я тоже делаю как-то так, но всегда с оговоркой, что из тех 11 месяцев, что ты будешь работать надо будет заплатить за налоги, отдых и в нагрузку получаешь риски, трекер и другие нюансы. Ведь как я писал выше как-то для себя нужно сравнивать эти подходы.
    Пока для меня никаких плюсов, кроме рейта, у кроссовера нет

    Как я написал ниже, лично для меня к плюсам я еще отнес удаленность работы — у кроссовера конечно не монополия на удаленную работу, но в сочетании с высоким рейтом я пока не нашел хороших альтернатив, где бы еще не было минусов кроссовера.
    Трекер наглядно показывает, что доверие у кроссовера к сотрудникам ниже плинтуса всегда и везде.

    Лично для меня трекер — это тоже сомнительная инновация, но я к нему достаточно быстро привык и какого-то чрезмерного дискомфорта не испытываю. Может из за этого не воспринимаю его как оголтелое недоверие сотрудникам. Для меня кроссовер — сервис, который предоставляет рабочий ресурс компаниям и трекер это просто средства организации этого — насколько он эффективный или этичный можно спорить, но если хочешь через него работать, то нужно быть согласным принимать для себя эти условия.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    0
    Всё верно, кроме того, что сравнивать нужно с $50 в час за похожую вакансию в кроссовере, написал про это выше.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    0
    Говорю об этом так уверенно, потому что до кроссовера я работал синьором и до сих пор меня приглашают на вакансии — я знаю какую зарплату предлагают мне. Сейчас даже после некоторого увеличения москвоских зарплат всё равно разница между тем сколько максимально можно зарабатывать на этой позиции в Москве сложно сравнивать с доходом через кроссовер. Разница примерно вдвое. Самая богатая вакансия, на которую меня приглашали была как раз 250к (типа тимлида что-то), в кроссовере же до всех налогов и други трат у меня яполучается около 500к. Конечно я заплачу за патент, отчисления в пенсионный, соц, банк, отложу на отпуск и больничный и всё равно сравнивать эти доходы не имеет смысла. И да, за эту разницу ты получаешь риски, гемор с трекером, ип, налогами и тд, что тут уже обсосали сто раз. Надо тебе такое или нет — тут каждый выбирает для себя.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    0
    Отношения левые — черная

    Оплата черная — это если ты её не регистрируешь в налоговой и не платишь с неё налоги. Что очевидно не так в случае с работой через кроссовер. Хотя я не финансовый эксперт — возможно есть какие-то схемы, позволяющие обойти уплату налогов с этих доходов, я просто про них не знаю. Но опять же, во-первых, это не то как работает кроссовер, ты сам выбираешь как себя вести дела с налоговой, а во-вторых, для ИП взаимодействие с налоговой дело не сказать чтобы очень хлопотное: да, надо купить патент, да заплатил за эльбу, за обслуживание в банке и валютный контроль, обмен на рубли на бирже по достаточно выгодному курсу — но это скажем порядка 30к-40к (пусть даже 50к) рублей в год для подмосковья — вообще не вижу смысла даже пытаться использовать черные схемы.
    Следовательно, эту сумму нельзя напрямую сравнивать с белой зарплатой нетто

    А кто сравнивает напрямую? В статье вроде достаточно подробно разбирается разница и указывается на необходимость платить с этой суммы налоги. Я лишь хотел сказать о том, что кроссовер оперирует той суммой, данные о которой у неё есть. Они эту сумму платят, а гросс будет зависеть от того какую систему налогообложения вы выберете, где вы зарегистрированы и тд.
    Т.е. в общем случае переработки кроссовером НЕ оплачиваются.

    В общем случае никто тебе не платит за переработку, если ты сам себе её инициировал. Т.е. даже если ты работаешь в офисе, то ты не можешь просидеть все выходные на работе, а потом прийти в бухгалтерию и потребовать за это время деньги, только если это было оговорено заранее с начальством или еще кем-то. Тоже самое и в кроссовере — менеджер говорит: у нас есть срочная работа, переработки оплачиваются. Если ты хочешь, ты можешь поработать сверх 40 часов и получить эти деньги. Переработка оплачивается по тому же рейту, да, но никто и не заставляет этим заниматься если не считаешь это приемлемым.
    никакой защиты у вас нет

    Это абсолютно верно, это риск, о котором нужно знать и понимать его выбирая договорную систему. Я бы даже в статье про это упомянул, потому что это важный момент, хоть он и не привлечет дополнительных работников. Я считаю, что такое предприятие как кроссовер должно быть максимально прозрачным, чтобы ему было хоть какое-то доверие — реакция в постах ясно дает понять, что сейчас доверие особенно у людей со стороны ниже плинтуса.
    заявленный годовой рейт рассчитан из 50 рабочих недель

    Видимо, чтобы была круглая сумма. Вообще когда обсуждается вакансия речь всегда идет о почасовой оплате и сумме за час, готовой доход это мне кажется маркетинговый ход какой-то, чтобы выглядело посолидней или просто оценочная сумма, чтобы сравнивать с другими.
    Это цена черной схемы.

    К сожалению, эта проблема есть у любого ИП, особенно работающего по патенту. Черная схема тут не причем.
    не позволяет напрямую сравнивать

    Напрямую — нет, потому что разница в рисках, оценить которые почти невозможно. Но сравнить всё равно как-то придется, если рассматриваешь такую схему для себя.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    0
    — Схема оплаты как раз белая. Трудовые/нетрудовые отношения, тут всё не очень прозрачно и конечно хотелось бы услышать оффициальный комментарий представителей кроссовера по этому поводу.
    — Сумма указана ровно такая, какую ты получаешь на руки, потому что ты сам занимаешься управлением своими финансами и волен выбирать вариант налогообложения удобный и выгодный тебе.
    — Переработки оплачиваются. Обычно без повышенного коэффициента и по договоренности с менеджером, но однозначно оплачиваются и никто тебя не заставит работать ни минуты больше 40 часов без твоего желания.
    — Трекинг, да, как следствие — получаешь денег ровно столько, сколько работал — можно к этому относиться негативно, но с другой стороны это определяет довольно четкие границы рабочих отношений.
    — Да, с тобой могут прекратить отношения, это очевидно негативный момент договорных отношений по сравнению с рабочими отношениями по ТК, однако обычно такого не случается — ведь хороших спциалистов не так много, а потребность в них высокая.
    — Уже не первый раз слышу о том, что отпусков и праздников 2 недели. Откуда такая инфа? Если и есть какие-то такие ограничения, я про них никогда не слышал — отпуск беру когда мне нужно и ограничение на длительность в первую очередь связано с тем, сколько я готов сидеть без оплаты. Наверное пол года не дадут, но месяц в год я гуляю как минимум. Более того видел как человек договаривался на 20 часовую рабочую неделю.
    — Да, ИП сложнее получить ипотеку и стоит она дороже и это безусловно негативный момент. Это общая проблема ИП в России. Нужно этот фактор учитывать, выбирая работу через ИП.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    0
    Примерно так оно и работает.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    0
    Справедливости ради хочу заметить, что позиция по ссылке это никак не Software Architect. Как минимум Chief Software Architect которому платят 100к. С названиями в кроссовере странная ситуация, потому что в реальной жизни эти позиции назывались бы что-то вроде разработчик и синьор-разрботчик, хотя второй часто выступает и в роли тех-лида.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    –1
    Унижает необходимость их носить.

    Ваша аналогия с кандалами никакой критики не выдерживает — ведь кандалы надевали рабам или заключенным, у обоих не было выбора носить их или нет. В данном случае же вы выбираете или не выбираете это абсолютно добровольно. Да и платят за это вам приличные деньги. Так что продолжить вашу метафору можно представив, что кандалы человек надел, потому что его наняли играть роль заключенного и носить их это его работа, за которую ему деньги платят и которую он сам себе выбрал. И тут как-то сразу унизительность пропадает почему-то. Думаю, потому, что ваши опусы с кандальниками — это демагогия чистой воды.
  • Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка
    0
    Здесь выше ведется дискуссия на счет трекера контроля времени, я могу высказать своё восприятие этого как человек работающий через эту систему. На мой взгляд трекер ничего хорошего работнику не дает, трекер вынуждает работать всё 40 часов, не вычитая из них чай, разминку, поход в туалет и тд. К тому же сейчас трекер кроссовера сделан так, что тарификация по десять минут крадет время работника. Это конечно не 10 часов в день, но 8 часов действительно приходится работать — это на грани возможностей, за неделю я действительно устаю. Тут много говорят, что мол слежка, скриншоты и тд — фантазия об этом реально пугает, по факту же через некоторое время от этих страхов остается только то о чем я написал до этого, да невозможность нормально чатиться. В том, что вас снимают раз в десять минут, действительно есть недоверие, вполне очевидное когда процесс поставлен на поток и обезличен, это способ формализовать этот процесс, с другой стороны у тебя есть менеджер, который тебя знает и может повлиять на какие-то моменты исходя из этого своего субъективного знания — в целом это пусть не идеально но работает. Резюмируя могу сказать, что у кроссовера есть множество негативных моментов, которые часто свойственны большим компаниям, где люди это поток, плюс отдельные проблемы, связанные с двумсмысленностью в отношении трудового законодательства, но я тем не менее выбрал работать через эту систему и пока переставать не собираюсь. Происходит это по двум основным причинам: 1. кроссовер для меня возможность получать доход вдвое больший, чем тот, что я получал и мог бы получать в Москве. При том, что учитывая все минусы о которых я писал выше, я работаю с командой вполне конкретных людей с которыми мне нравится работать, я занимаюсь достаточно интересной работой (это кстати как повезет, но мне повезло — это нез начит, что нет рутины или что не надо набивать метрики, всё это надо делать, просто этим работа не ограничивается), т.е. я делаю работу, которая приносит мне удовлетворение за деньги, которые мне больше никто не может предложить за ту же работу. 2. это удаленная работа, мы с семьей имеем возможность ездить в теплые страны на длительное время — например зимовать в Тае. Эти два фактора имеют ключевое значение для моего выбора и перевешивают минусы, ко многим из которых я привык и они не создают для меня значительных проблем. Поэтому когда я читаю этот пост я согласен со многими, кто пишет негатив, но с другой я знаю, что некоторые из этих моментов не настолько критичны, с некоторыми можно смириться ради значительно увеличенного дохода и некоторой свободы перемещения. Что это возможность, которой могут воспользоваться люди, которым она подходит.
  • Swift vs. Kotlin. Отличия важны
    +1
    да, прошу прощения, неправильно понял, всё верно про возможность мокировать по тайпклассу. Очень это приятная фича, которой нет в жвм платформе. Есть реализация в форке котлина, но у этого всего плохая совместимость с джавой и сложность в корректной поддержке во всех аспектах, так что не факт, что тайпклассы появятся даже как экспериментальная фича в котлине
  • Swift vs. Kotlin. Отличия важны
    0
    А это совсем не то, чего я хотел.

    Именно — передача по ссылке/значению очень субъективно. Лично на мой взгляд, передача по ссылке по-умолчанию на порядок удобнее и логичнее. Особенно если мои дата-классы иммутабельные. А если надо скопировать, то есть метод `copy` из коробки. Конечно бывают кейзы, когда хотелось бы иметь value-типы и в жвм возможно их скоро завезут, но таких случаев значительно меньше, чем те, что покрываются обычными дата-классами.

    Вы можете создать свой протокол и расширение для класса, чтоб соответствовать этому протоколу.

    Да это приятная фича языка поддерживаемая платформой (в отличии от жвм), только примеры про неё ничего не говорят.
    Это может быть сложно даже с Mockito

    Серьезно? Если у вас есть интерфейс, нет никакой проблемы замокировать его. С файналами не так всё просто конечно, но пример совершенно это не показывает.
    Они отличаются только названием и, конечно же, sealed-класс передается по ссылке, а перечисление в Swift — по значению.

    Сначала опять про ссылки и значения. Для перечислений нет никакой разницы, передавать адрес константы или её номер. А для sealed-классов, та же дилемма, что и в первом пункте. И да, различий нет уж и много, но они есть.
  • Dependency injection
    +2
    Разве эти поля не должны быть private final? В этом одно из преимуществ внедрения в конструктор.
  • Как сделать Java код проще и нагляднее
    +2
    кажется что эта логика может быть переиспользована

    вы так говорите, как будто логику в методы выносят только для переиспользования
    Либо, можно спрятать такие вычисления в Supplier

    или намного проще, визуально понятнее и быстрее «спрятать» их в метод. Понимаю, вы подсмотрели этот паттрен в джаваскрипте, но в джаве он слишком громоздкий. В котлине еще как-то можно было бы что-то такое с инлайн-функциями провернуть
    val result = run { "got it" }
    и то редко такое может пригодиться.
  • Как сделать Java код проще и нагляднее
    +2
    Так почему же из него метод не сделать? если это N строк, которые вычисляют определенное значение и например могут быть протестированы и вообще могут не мозолить глаза своими деталями?
  • Как сделать Java код проще и нагляднее
    +3
    isSupportedBrowser = ((Supplier<boolean>)()->{ … }).get();

    этим вы предлагаете заменить хорошо названный метод?
  • И на улицу JavaFX тоже придет Spring
    0
    Суровая интеграция, бессмысленная и беспощадная.
  • Linux-2018: самые перспективные дистрибутивы
    0
    Виртуалбокс сейчас работает без особых проблем, раньше не знаю, пользуюсь элементариос месяцев 8.
  • REST — это новый SOAP
    +1
    Но, если пользователи не могут войти в свой аккаунт, то как они «вычищают» их? Т.е. вся ситуация выглядит притянутой за уши.

    Этот пример просто показывает, что смешение транспортного уровня и уровня логики приводит к такого рода ошибкам. А вычистить из за такой ошибки пользователей вообще ничего не стоит, потому что где-то на другом серваке стоит другой сервис, который синхронизирует пользователей себе локально, для чего обращается к нашему и если видит, что его уже нет, то удаляет и у себя, например. Это взятый из головы пример, но в целом вероятный. Суть проблемы в том, что вызывающий скприт не понял, что тот 404 который пришел, он совсем не про то.
    как раз потому что к моим сервисам обращались автономные программы, которые по коду понимали, что делать дальше

    Какой http-код вы возвращаете если вам нужно сказать клиенту, что транзакция длилась слишком долго и была отменена?
    Публичные API, с которыми приходилось работать, тоже использовали коды по назначению.

    Всё верно, проблема только, что на все случаи кодов нет и особенно для более сложных api всё равно приходится что-то придумывать сверх того, что есть.
    … либо потому что привык к другой среде, о чём я и написал в заключении.

    В заключении вы говорите о том, что автор привык к soap, хотя автор недвусмысленно намекает, что проще было бы место soap-а и rest-а использовать какие-то простые http-rpc. Что наводит меня на мысль, что вы или не знаете, что имеет ввиду автор или просто не читали, но осуждаете.
    И даже если допустить, что статью целиком я не понял, отдельные фразы вроде указанных выше интерпретировать иначе чертовски сложно.

    Но возможно местами, если всё же вникнуть в написанное.