где скачать компилятор/интерпретатор языка, а лучше сразу онлайн песочница.
вот смотрите бенчмарк тесты на таких то и таких задачах.
вот тут репозиторий (если это опенсорс) а вот тут формируется сообщество (если нет), все сюда!
а вот тут репозиторий проекта (достаточно крупного чтобы оценить удобство) на этом языке.
хотя бы так. если вы стартуете с нуля. вообще для его принятия рынком потребуется намного больше.
P. S. если ваш язык универсален - скорее всего он бесполезен. исключений немного, и все они или разрабатывались или крупными компаниями и экспертам с огромными опытом, или прошли десятки лет развития в опенсорс. сфокусируйтесь на чем то, на какой то области, чем уже тем лучше, и закройте все её потребности в чем то лучше чем мейнстрим язык в этой области. иначе никому нет смысла его принимать для реального проекта. новый язык это ОЧЕНЬ дорого. после успеха (если будет) можете выпустить новый, на базе этого но более универсальный , с учётом полученного опыта и с ресурсами на его распространение и создание необходимой инфраструктуры (фреймворк и прочие) . под ресурсами тут имеется ввиду не столько деньги сколько репутация и возможность запартнерить других людей и компании на создание инфраструктуры и использование в своих проектах.
хотя если это просто фан проект то не обязательно. но тогда не расстраивайтесь если он никому не будет нужен. потому что люди не используют новые языки просто так, потому что захотелось или потому что у него есть фишки работы с пямятью. просто представьте себя на месте техдира который решит его использовать для продукта. новый язык это как минимум обучение ему с нуля всех новых разработчиков. 4-6 зарплат на каждого вынь да положь. и так при любой смене разработчика. и это не самая большая проблема. даже не в первой десятке. просто самая наглядная.
детский сад какой то. в соглашении, в котором пользователь галочку ставит, прописываете право выкупа и максимальную цену.
если в наглую то и игровой валютой или игровыми плюшками можно. но все же для репутации полезнее за реальные, проще будет негативную шумиху убрать. сложно игроку будет шуметь о справедливости когда ему предложили скажем 10к $, или кучу игровых плюшек, в качестве извинения и компенсации за баг который по сути нарушает игровой баланс, портит игру всем и его использование является читом и эксплоитом.
юридически задница полноценно прикрыта соглашением и статусом (и свойствами) этого крипто актива.
ближайшая аналогия к любому крипто активу (на данный момент) это именная ценная бумага, а там все зависит от условий того кто её выпускает (тот кто приобретает по умолчанию с ними соглашается, иначе нефик приобретать). и право приоритетного выкупа по фиксировпнной цене или запрет на продажу третьим лицам это банальная банальщина.
боятся стоит не восстания машин, там можно пытаться противодействовать.
боятся нужно добровольной передачи принятия всех решений ИИ, там никто противодействовать не будет. зачем, всем уютно, эффективно, конкурентоспособно. и проблема в том что это процесс постепенный. он не случится сразу вдруг, он начнётся с простого, с систем аналитики и выдачи возможных решений, с систем автоматизации менеджмента, с персональных ассистентов, диетологов и рекомендательных сервисов рпзвлесений. шаг за шагом, задача за задачей, от бизнеса к управлению государствами и далее к глобальным процессам, от экономики до насточивых рекомендаций по диете и матчинга партнера. это процесс нельзя остановить после его полноценного начала, потому что те кто не используют будут в очень невыгодном положении. их "выщемят с рынка". они станут устаревшими, неэфективными, странными.
само собой речь не про генеративные модели. но мы же в целом про ИИ говорим. и само собой на это уйдёт время.
боятся нужно что мы (ну точнее наши потомки в 4-5 поколении после появления более менее полноценных ИИ) , как вид, повторим судьбу наших питомцев, кошечек, собачек, хомячков. и будем жить в счастливом мире с идеальной экономикой, отличной экологией, побежденными болезнями, голодом, нищетой, и полным отсутствием возможности, а главное желания, что то решать, планировать, развиваться, думать (за пределами самых базовых вещей) . как цивилизация мы исчезнем. как вид, да и каждый персонально, мы конечно будем в полном шоколаде, как любимый мопсик богатой скучающей домохозяйки. цивилизации жалко. столько шли, развивались, чтобы потом так нелепо схлопнуться об один из самых простых барьеров.
главное же коммуникация. если вы работаете на заводе в компании людей 50+, всю жизнь проработавших на этом же заводе, для которых летучка и ЭВМ гораздо понятнее дейлика и компьютера - без проблем, оптимально будет называть их именно так.
в той среде в которой работаю я и большинство IT у вас будут проблемы с коммуникацией.
говорите на том языке на котором говорят люди.
язык он ведь гибкий и саморегулируемый. "дейлик" и "митинг" позаимствовпли, "созвон" оставили. компьютер позаимствлвали, клавиатуру нет. он развивается так как ему удобно. никто не сидит с печатью и не утверждает что и как называть.
можете везде говорить летучка и ЭВМ, да у вас будут сложности с коммуникацией (простите, общением конечно же) в большинстве случаев, но никто вам не запрещает же. просто неудобно.
вы хотите навязать чтобы все общались так как привычно вам? ну попробуйте, хотя я уже знаю куда вас пошлют.
p. s. некоторые термины в принципе не переводятся потому что аналога нет, хотя кажется что есть. "летучка" традиционно это проверка статусов и раздача задач. быстрая. перед работой. в соответствии с традициями управления в СССР, от начальника к подчиненным. вот только нормальные дейлики совсем не про это. но это уже другая история.
это есть почти в любой нормальной IT компании. нет банк, завод или интернет провайдер это не IT компания, даже если там есть "IT департамент". ну и исключаем всяких интеграторов, локализаторов и самые галерные галеры работающие на аутстаф за еду. ну и работающие на гос подряд само собой.
любая нормальная комапания будет стремится к самоорганизованным командам потому что это радикально повышает все параметры, от эффективности и качества до предсказуемого деливери новых фич и задач. и главной проблемой обычно является научить людей организовыватся, и уж точно мало кто целенаправленно этому мешает.
просто найдите нормальную работу. вполне возможно что для этого придётся выучить английский и работать удалённо, или релоцироватся.
нет faang для этого совсем не обязателен, скорее наоборот, у них как у любых крупных компаний все же уровень бюрократищма выше, хоть они и борются с этим. компании среднего уровня, стартапы, нормальные аутсорсеры где ценят сотрудников. это все можно выяснить на собесе и подтвердить в первые месяцы работы.
серьезно, ваше "я таких команд не видел" звучит как будто вы всю жизнь просидели в подвале завода, в глубинке, заправляя принтеры, под управлением начальника сумасброда, который вообще не в курсе чем управляет.
самоуправляемые, самоорганизующиеся команды, уже лет 10 стандарт отрасли, норма, ну за редкими исключениями.
если команда реально считает что дейлики ей не нужны то может их отменить. или сделать реже. в чем проблема то?
команда должна понять что процесс нужен не менеджменту, а в первую очередь им самим. что она решает их проблемы и упрощает им жизнь. тогда она сможет понять как им адаптировать его под себя.
как понять?
можно например поломать процесс и устроить полный хаос. это дорого, зато те кто всю жизнь работал в более менее нормальных процессах и ныл "зачем это нужно, не отвлекайте меня от работы" довольно неплохо осознают "зачем все это нужно".
можно нанимать сразу адекватных разработчиков, которые не только знают что будет при выполнении вот этого кода (сарказм) но и понимают разработку в целом, процессы, другие роли, и прочее, а не только свою узкую область и задачу.
много чего можно. скрам кстати тоже не обязателен, можно например на канбан переключиться если удобнее, на время или навсегда. можно смешать но не взбалтывать. или что то другое. или что то свое. по ситуации. тут ведь главное что, чтобы команда была проактивной в вопросах самоуправления, понимала зачем это нужно и адаптировала процесс под свои потребности. а не сидели и ныои "вот нас заставляют". вот исходя из этого перечитайте мой комментарий выше, и думаю поймёте что никакой манипуляции там нет, лишь обращен описание основных, самых шаблонных, проблем в построении процессов и командной работы в целом.
при том что IT глобальный, за редкими исключениями. редкие исключения могут вводить свою терминологию если им нужно. но тогда не стоит удивляться что их никто не понимает. никто не будет менять общую терминологию чтобы удовлетворить желания редких исключений.
просто разберитесь что такое канбан в IT. Всё. просто разберитесь.
вы же не думаете что вам в рот засунут много многотонных железных и бетонных балок когда стоматолог говорит что нужно ставить мост?
легенда это хорошо, но вы, вместо того чтобы научится, предлагаете всем легендировать всем понятные, базовые, давно всеми используемые термины.
понимаете как это выглядит? пришёл новичок из другой области и вместо того чтобы разобраться в терминологии новой для него области, требует "давайте все переведём как мне удобно, потому что надо на русском, я учился на машиностроителя! и легенду мне!". вы когда "учились на машиностроителя" слова "колесо" и "шестерня" легендировали? беспокоились что никто не перепутать сварку с варкой? изучите терминологии и не страдацте ерундой. и директору своему объясните что гуглить не стыдно.
это стандарт отрасли. жаргон. лексикон. это то что говорят, понимают и не страдают ерундой.
он сформировался полным англицизмов потому что IT отрасль сильно глобализированная. общение, совместная работа, обмен опытом, конференции, книги, статьи, блоги, документация и прочее и прочее. и все это в основном на английском или переведено с него. это просто глупо и неудобно переводить для локального использования "летучка" когда все вокруг называют это, daily, DS или stand up.
я говорил про международные команды, в них могут быть китайцы, американцы, русские, швейцарцы, казахи, канадцы, британцы и немцы. и все вполне неплохо говорят по английски, потому что а без вариантов, иначе никак, те кто не говорят не будут в команде так как не смогут работать. и это не экзотика, это современная норма в IT отрасли.
если честно, ваш пример с директором меня вводит в ступор и вызывает кучу вопросов. зачем он использует слова которых не понимает? зачем он придумывает свои смыслы для слов? почему просто не погуглит? что за услуга по привлечению мигрантов? что он делает в роли директора если не разбирается в самых базовых схемах работы с контракторами? короче много вопросов к квалификации директора.
а аутстаффинг это предоставление своего персонала (в своей компании, на своей территории) для решения задач клиента под управлением клиента. то есть люди наши, менеджмент и задачи ваши.
и это знает почти каждый мидл, просто потому что сталкивался, это знает абсолютно каждый менеджер а IT любого уровня, это распространённое понятие. очень.
чтобы у вас был скрам надо не делать по гайду, а надо чтобы вся команда понимала зачем нужен процесс, каждая его деталь и в каком виде, и (так как это аджайл процесс) могла адекватно и взвкшенно адаптировать его под свои нужды.
если скрам вводят директивно ничего не объясняя и не адаптируя под потребности - это не скрам, это срам.
если те кто его вводят не понимают зачем он нужен и почему именно он - это не скрам, это срам.
если процесс постоянно нарушается и "сверху" и "снизу", и от скрама остаются только формальные спринты и отчёты по утрам - это не скрам, это срам.
если команда состоит из тех кто "задачи из жиры пилит" и им плевать и на процессы и на продукт и на эффективность - это не скрам это хрень.
если в команде никто не понимает нафига вообще нужны все эти митинги, процессы и прочая развлекуха менеджеров, когда можно просто кайфовать от программирования 24х7 - это не скрам, это надо их собрать и отправить на хакатоны, пусть креативят, кайфуют и не мешают делать продукт, разработка это в первую очередь бизнес а потом уже дрим тим, креатив и кайф от программирования.
вы когда нибудь работали в международной команде? готовы объяснить китайцу на английском что такое "летучка" и почему именно это слово надо использовать вместо привычного всему миру (в отрасли) scrum, daily или stand up?
почему вы сидите в своих узких ящиках и мыслите в них же? мир шире чем то что вам привычно и знакомо. но вместо того чтобы разобраться вы ноете и филосовствуете о продаже слов. наверняка при этом ещё и ощущая себя офигенно мудрым.
а вы просто представьте что никакого дефицита нет. вот как авторы статьи. статистику там посмотрите что ли от создателей 146%, мантры почитайте. сразу на душе легче станет.
загляни в composer. json, там все написано.
если там не написано, загляни в Dockerfile и docker-compose. yml
блин, а мужики то не знают что php в high-load не работает, так и пилят свои приложения для сотен миллионов пользователей в день.
пойду сообщу что ли. что не должно это работать, так на хабре написали.
давайте я расскажу как правильно:
какие задачи решает язык?
по каким параметрам этот язык лучше чем язык Х.
где скачать компилятор/интерпретатор языка, а лучше сразу онлайн песочница.
вот смотрите бенчмарк тесты на таких то и таких задачах.
вот тут репозиторий (если это опенсорс) а вот тут формируется сообщество (если нет), все сюда!
а вот тут репозиторий проекта (достаточно крупного чтобы оценить удобство) на этом языке.
хотя бы так. если вы стартуете с нуля. вообще для его принятия рынком потребуется намного больше.
P. S. если ваш язык универсален - скорее всего он бесполезен. исключений немного, и все они или разрабатывались или крупными компаниями и экспертам с огромными опытом, или прошли десятки лет развития в опенсорс. сфокусируйтесь на чем то, на какой то области, чем уже тем лучше, и закройте все её потребности в чем то лучше чем мейнстрим язык в этой области. иначе никому нет смысла его принимать для реального проекта. новый язык это ОЧЕНЬ дорого. после успеха (если будет) можете выпустить новый, на базе этого но более универсальный , с учётом полученного опыта и с ресурсами на его распространение и создание необходимой инфраструктуры (фреймворк и прочие) . под ресурсами тут имеется ввиду не столько деньги сколько репутация и возможность запартнерить других людей и компании на создание инфраструктуры и использование в своих проектах.
хотя если это просто фан проект то не обязательно. но тогда не расстраивайтесь если он никому не будет нужен. потому что люди не используют новые языки просто так, потому что захотелось или потому что у него есть фишки работы с пямятью. просто представьте себя на месте техдира который решит его использовать для продукта. новый язык это как минимум обучение ему с нуля всех новых разработчиков. 4-6 зарплат на каждого вынь да положь. и так при любой смене разработчика. и это не самая большая проблема. даже не в первой десятке. просто самая наглядная.
а все остальные в сообществе?
детский сад какой то. в соглашении, в котором пользователь галочку ставит, прописываете право выкупа и максимальную цену.
если в наглую то и игровой валютой или игровыми плюшками можно. но все же для репутации полезнее за реальные, проще будет негативную шумиху убрать. сложно игроку будет шуметь о справедливости когда ему предложили скажем 10к $, или кучу игровых плюшек, в качестве извинения и компенсации за баг который по сути нарушает игровой баланс, портит игру всем и его использование является читом и эксплоитом.
юридически задница полноценно прикрыта соглашением и статусом (и свойствами) этого крипто актива.
ближайшая аналогия к любому крипто активу (на данный момент) это именная ценная бумага, а там все зависит от условий того кто её выпускает (тот кто приобретает по умолчанию с ними соглашается, иначе нефик приобретать). и право приоритетного выкупа по фиксировпнной цене или запрет на продажу третьим лицам это банальная банальщина.
а в чем проблема?
просто выкупите у игроков эти мечи.
боятся стоит не восстания машин, там можно пытаться противодействовать.
боятся нужно добровольной передачи принятия всех решений ИИ, там никто противодействовать не будет. зачем, всем уютно, эффективно, конкурентоспособно. и проблема в том что это процесс постепенный. он не случится сразу вдруг, он начнётся с простого, с систем аналитики и выдачи возможных решений, с систем автоматизации менеджмента, с персональных ассистентов, диетологов и рекомендательных сервисов рпзвлесений. шаг за шагом, задача за задачей, от бизнеса к управлению государствами и далее к глобальным процессам, от экономики до насточивых рекомендаций по диете и матчинга партнера. это процесс нельзя остановить после его полноценного начала, потому что те кто не используют будут в очень невыгодном положении. их "выщемят с рынка". они станут устаревшими, неэфективными, странными.
само собой речь не про генеративные модели. но мы же в целом про ИИ говорим. и само собой на это уйдёт время.
боятся нужно что мы (ну точнее наши потомки в 4-5 поколении после появления более менее полноценных ИИ) , как вид, повторим судьбу наших питомцев, кошечек, собачек, хомячков. и будем жить в счастливом мире с идеальной экономикой, отличной экологией, побежденными болезнями, голодом, нищетой, и полным отсутствием возможности, а главное желания, что то решать, планировать, развиваться, думать (за пределами самых базовых вещей) . как цивилизация мы исчезнем. как вид, да и каждый персонально, мы конечно будем в полном шоколаде, как любимый мопсик богатой скучающей домохозяйки. цивилизации жалко. столько шли, развивались, чтобы потом так нелепо схлопнуться об один из самых простых барьеров.
какие понятия из данной статьи, по вашему, нуждаются в "расшифровке" ?
ок, думайте.
да на самом деле никто не мешает, используйте.
главное же коммуникация. если вы работаете на заводе в компании людей 50+, всю жизнь проработавших на этом же заводе, для которых летучка и ЭВМ гораздо понятнее дейлика и компьютера - без проблем, оптимально будет называть их именно так.
в той среде в которой работаю я и большинство IT у вас будут проблемы с коммуникацией.
говорите на том языке на котором говорят люди.
язык он ведь гибкий и саморегулируемый. "дейлик" и "митинг" позаимствовпли, "созвон" оставили. компьютер позаимствлвали, клавиатуру нет. он развивается так как ему удобно. никто не сидит с печатью и не утверждает что и как называть.
можете везде говорить летучка и ЭВМ, да у вас будут сложности с коммуникацией (простите, общением конечно же) в большинстве случаев, но никто вам не запрещает же. просто неудобно.
вы хотите навязать чтобы все общались так как привычно вам? ну попробуйте, хотя я уже знаю куда вас пошлют.
p. s. некоторые термины в принципе не переводятся потому что аналога нет, хотя кажется что есть. "летучка" традиционно это проверка статусов и раздача задач. быстрая. перед работой. в соответствии с традициями управления в СССР, от начальника к подчиненным. вот только нормальные дейлики совсем не про это. но это уже другая история.
это есть почти в любой нормальной IT компании. нет банк, завод или инт![]()
ернет провайдер это не IT компания, даже если там есть "IT департамент". ну и исключаем всяких интеграторов, локализаторов и самые галерные галеры работающие на аутстаф за еду. ну и работающие на гос подряд само собой.
любая нормальная комапания будет стремится к самоорганизованным командам потому что это радикально повышает все параметры, от эффективности и качества до предсказуемого деливери новых фич и задач. и главной проблемой обычно является научить людей организовыватся, и уж точно мало кто целенаправленно этому мешает.
просто найдите нормальную работу. вполне возможно что для этого придётся выучить английский и работать удалённо, или релоцироватся.
нет faang для этого совсем не обязателен, скорее наоборот, у них как у любых крупных компаний все же уровень бюрократищма выше, хоть они и борются с этим. компании среднего уровня, стартапы, нормальные аутсорсеры где ценят сотрудников. это все можно выяснить на собесе и подтвердить в первые месяцы работы.
серьезно, ваше "я таких команд не видел" звучит как будто вы всю жизнь просидели в подвале завода, в глубинке, заправляя принтеры, под управлением начальника сумасброда, который вообще не в курсе чем управляет.
самоуправляемые, самоорганизующиеся команды, уже лет 10 стандарт отрасли, норма, ну за редкими исключениями.
кто изгонит? куда изгонит?
если команда реально считает что дейлики ей не нужны то может их отменить. или сделать реже. в чем проблема то?
команда должна понять что процесс нужен не менеджменту, а в первую очередь им самим. что она решает их проблемы и упрощает им жизнь. тогда она сможет понять как им адаптировать его под себя.
как понять?
можно например поломать процесс и устроить полный хаос. это дорого, зато те кто всю жизнь работал в более менее нормальных процессах и ныл "зачем это нужно, не отвлекайте меня от работы" довольно неплохо осознают "зачем все это нужно".
можно нанимать сразу адекватных разработчиков, которые не только знают что будет при выполнении вот этого кода (сарказм) но и понимают разработку в целом, процессы, другие роли, и прочее, а не только свою узкую область и задачу.
много чего можно. скрам кстати тоже не обязателен, можно например на канбан переключиться если удобнее, на время или навсегда. можно смешать но не взбалтывать. или что то другое. или что то свое. по ситуации. тут ведь главное что, чтобы команда была проактивной в вопросах самоуправления, понимала зачем это нужно и адаптировала процесс под свои потребности. а не сидели и ныои "вот нас заставляют". вот исходя из этого перечитайте мой комментарий выше, и думаю поймёте что никакой манипуляции там нет, лишь обращен описание основных, самых шаблонных, проблем в построении процессов и командной работы в целом.
при том что IT глобальный, за редкими исключениями. редкие исключения могут вводить свою терминологию если им нужно. но тогда не стоит удивляться что их никто не понимает. никто не будет менять общую терминологию чтобы удовлетворить желания редких исключений.
просто разберитесь что такое канбан в IT. Всё. просто разберитесь.
вы же не думаете что вам в рот засунут много многотонных железных и бетонных балок когда стоматолог говорит что нужно ставить мост?
легенда это хорошо, но вы, вместо того чтобы научится, предлагаете всем легендировать всем понятные, базовые, давно всеми используемые термины.
понимаете как это выглядит? пришёл новичок из другой области и вместо того чтобы разобраться в терминологии новой для него области, требует "давайте все переведём как мне удобно, потому что надо на русском, я учился на машиностроителя! и легенду мне!". вы когда "учились на машиностроителя" слова "колесо" и "шестерня" легендировали? беспокоились что никто не перепутать сварку с варкой? изучите терминологии и не страдацте ерундой. и директору своему объясните что гуглить не стыдно.
это стандарт отрасли. жаргон. лексикон. это то что говорят, понимают и не страдают ерундой.
он сформировался полным англицизмов потому что IT отрасль сильно глобализированная. общение, совместная работа, обмен опытом, конференции, книги, статьи, блоги, документация и прочее и прочее. и все это в основном на английском или переведено с него. это просто глупо и неудобно переводить для локального использования "летучка" когда все вокруг называют это, daily, DS или stand up.
я говорил про международные команды, в них могут быть китайцы, американцы, русские, швейцарцы, казахи, канадцы, британцы и немцы. и все вполне неплохо говорят по английски, потому что а без вариантов, иначе никак, те кто не говорят не будут в команде так как не смогут работать. и это не экзотика, это современная норма в IT отрасли.
если честно, ваш пример с директором меня вводит в ступор и вызывает кучу вопросов. зачем он использует слова которых не понимает? зачем он придумывает свои смыслы для слов? почему просто не погуглит? что за услуга по привлечению мигрантов? что он делает в роли директора если не разбирается в самых базовых схемах работы с контракторами? короче много вопросов к квалификации директора.
а аутстаффинг это предоставление своего персонала (в своей компании, на своей территории) для решения задач клиента под управлением клиента. то есть люди наши, менеджмент и задачи ваши.
и это знает почти каждый мидл, просто потому что сталкивался, это знает абсолютно каждый менеджер а IT любого уровня, это распространённое понятие. очень.
чтобы у вас был скрам надо не делать по гайду, а надо чтобы вся команда понимала зачем нужен процесс, каждая его деталь и в каком виде, и (так как это аджайл процесс) могла адекватно и взвкшенно адаптировать его под свои нужды.
если скрам вводят директивно ничего не объясняя и не адаптируя под потребности - это не скрам, это срам.
если те кто его вводят не понимают зачем он нужен и почему именно он - это не скрам, это срам.
если процесс постоянно нарушается и "сверху" и "снизу", и от скрама остаются только формальные спринты и отчёты по утрам - это не скрам, это срам.
если команда состоит из тех кто "задачи из жиры пилит" и им плевать и на процессы и на продукт и на эффективность - это не скрам это хрень.
если в команде никто не понимает нафига вообще нужны все эти митинги, процессы и прочая развлекуха менеджеров, когда можно просто кайфовать от программирования 24х7 - это не скрам, это надо их собрать и отправить на хакатоны, пусть креативят, кайфуют и не мешают делать продукт, разработка это в первую очередь бизнес а потом уже дрим тим, креатив и кайф от программирования.
так я вроде и не вам писал. что вы шутили вроде видно.
вы когда нибудь работали в международной команде? готовы объяснить китайцу на английском что такое "летучка" и почему именно это слово надо использовать вместо привычного всему миру (в отрасли) scrum, daily или stand up?
почему вы сидите в своих узких ящиках и мыслите в них же? мир шире чем то что вам привычно и знакомо. но вместо того чтобы разобраться вы ноете и филосовствуете о продаже слов. наверняка при этом ещё и ощущая себя офигенно мудрым.
а вы просто представьте что никакого дефицита нет. вот как авторы статьи. статистику там посмотрите что ли от создателей 146%, мантры почитайте. сразу на душе легче станет.