На самом деле я вам очень благодарен, хотя бы за то, что вы не только обратили внимание на мое творчество, а еще и написали объективные комментарии. Планировалось провести через весь цикл, показать черновую работу и я думаю кому то это будет полезно, ведь добавляет же кто то посты в закладки. В свое время я искал примеры создания проектов на Angular и их было очень мало. Сегодня я пришел к тому, что мне хочется показать пример создания приложения которое кардинально отличается от тудушек и кликеров, даже если это и не перевод, а личное творчество. Для себя я сделал вывод, что писать на такие темы очень сложно, но это не уменьшает их ценности. К тому же, я внимательно ознакомился с правилами и очень рад, что вы следуете этому правилу: “Не злоупотребляйте своей возможностью голосования. Необходимо понимать, что минус сильно отличается от плюса — минус угнетает человека, а не развивает его. Ставьте плюсы, когда вам что-то нравится, но подумайте, прежде чем ставить минус, если что-то не понравилось”.
Ну и мои любимые правила Хабра гласят - Минус — это не аргумент, и, тем более, не контраргумент. Не делай другим то, что не хочешь получить от них сам. Помогайте другим там, где вы это можете делать.
Флаг strict напрямую связан с проверкой типов. Его включение автоматически активирует абсолютно все флаги секции Strict Checks, включая и alwaysStrict. У такого подхода есть как минимум один недостаток – неочевидность. Устанавливая strict: true, нет наглядного представления, какие именно проверки включены и какие опции вообще существуют. Для проектов, которые с самого начала пишутся на TypeScript это не так принципиально, как для проектов, которые поэтапно портируются с JavaScript.
В процессе портирования существующего приложения нет возможности сразу включить все проверки. Приходится активировать их по одной шаг за шагом. Иногда даже случаются сложности, из-за которых приходится откатывать ранее установленные флаги обратно в false.
Есть небольшая особенность работы флага strict – список подконтрольных ему флагов может пополняться по мере выхода новых версий TypeScript. Подобные моменты если случаются, то редко и всегда освещаются в release notes если, конечно, вы их читаете перед обновлением версии.
Лично я предпочитаю указывать список флагов явным образом
Нет, не спрашивали. Отчасти потому, что у меня сложилась такая репутация, отчасти потому, что дополнительно происходило документальное отслеживание (к накладным прикладывались акты и бумажные чеки).
Да, почему то embedded engineering не котируется, я думаю отчасти это связано с тем, что сделаное однажды устройство можно тиражировать долгие годы не изменяя прошивку, к тому же можно эту прошивку снять(пиратство процветает). А вот для себя очень даже полезно. Как пример могу привести случай из жизни. У меня стабильно начала ломатся насосная станция, то шланг прорвало, то сгорела так как не выключалась, бо я по не знанию давление накрутил выше нормы. А станция находится в приямке, так купил я датчик давления на aliexpress, убил пару выходных и вывел показания на екранчик, поставил модуль ethernet, развернул сервер, написал примитивный алгоритм с оповещением и забыл о тревогах по поводу работы насоса. Примитивно конечно, но в хозяйстве самое то)
Да вроде пока и не фигота). Тем более на предыдущем месте было очень интересно, к тому же удалось проявить свои управленческие качества, помочь сделать проект более устойчивым к нагрузкам. На новом месте тоже очень интересно, думаю и здесь найду чем быть более полезным.
Вы правы, Айтишник должен нести добро и свет, а не это всё. В первую очередь я выбирал не должность, а людей с которыми придется работать. На собеседовании будущее руководство произвело на меня очень хорошее впечатление и я ни разу не пожалел о своем выборе.
На самом деле я вам очень благодарен, хотя бы за то, что вы не только обратили внимание на мое творчество, а еще и написали объективные комментарии. Планировалось провести через весь цикл, показать черновую работу и я думаю кому то это будет полезно, ведь добавляет же кто то посты в закладки. В свое время я искал примеры создания проектов на Angular и их было очень мало. Сегодня я пришел к тому, что мне хочется показать пример создания приложения которое кардинально отличается от тудушек и кликеров, даже если это и не перевод, а личное творчество. Для себя я сделал вывод, что писать на такие темы очень сложно, но это не уменьшает их ценности. К тому же, я внимательно ознакомился с правилами и очень рад, что вы следуете этому правилу: “Не злоупотребляйте своей возможностью голосования. Необходимо понимать, что минус сильно отличается от плюса — минус угнетает человека, а не развивает его. Ставьте плюсы, когда вам что-то нравится, но подумайте, прежде чем ставить минус, если что-то не понравилось”.
Ну и мои любимые правила Хабра гласят - Минус — это не аргумент, и, тем более, не контраргумент. Не делай другим то, что не хочешь получить от них сам. Помогайте другим там, где вы это можете делать.
Флаг
strictнапрямую связан с проверкой типов. Его включение автоматически активирует абсолютно все флаги секцииStrict Checks, включая иalwaysStrict. У такого подхода есть как минимум один недостаток – неочевидность. Устанавливаяstrict: true, нет наглядного представления, какие именно проверки включены и какие опции вообще существуют. Для проектов, которые с самого начала пишутся на TypeScript это не так принципиально, как для проектов, которые поэтапно портируются с JavaScript.В процессе портирования существующего приложения нет возможности сразу включить все проверки. Приходится активировать их по одной шаг за шагом. Иногда даже случаются сложности, из-за которых приходится откатывать ранее установленные флаги обратно в
false.Есть небольшая особенность работы флага
strict– список подконтрольных ему флагов может пополняться по мере выхода новых версий TypeScript. Подобные моменты если случаются, то редко и всегда освещаются в release notes если, конечно, вы их читаете перед обновлением версии.Лично я предпочитаю указывать список флагов явным образом
Нет, не спрашивали. Отчасти потому, что у меня сложилась такая репутация, отчасти потому, что дополнительно происходило документальное отслеживание (к накладным прикладывались акты и бумажные чеки).
Читал много таких статей и понравилось именно "вайти" - это как "тыжпрограмист")
Спасибо, рад, что вам было интересно
Почитал кто такой Григорий Бакунов, в отличии от меня он очень крут. Спасибо за такой теплый комментарий, очень согревает и мотивирует
Да, почему то embedded engineering не котируется, я думаю отчасти это связано с тем, что сделаное однажды устройство можно тиражировать долгие годы не изменяя прошивку, к тому же можно эту прошивку снять(пиратство процветает). А вот для себя очень даже полезно. Как пример могу привести случай из жизни. У меня стабильно начала ломатся насосная станция, то шланг прорвало, то сгорела так как не выключалась, бо я по не знанию давление накрутил выше нормы. А станция находится в приямке, так купил я датчик давления на aliexpress, убил пару выходных и вывел показания на екранчик, поставил модуль ethernet, развернул сервер, написал примитивный алгоритм с оповещением и забыл о тревогах по поводу работы насоса. Примитивно конечно, но в хозяйстве самое то)
Да вроде пока и не фигота). Тем более на предыдущем месте было очень интересно, к тому же удалось проявить свои управленческие качества, помочь сделать проект более устойчивым к нагрузкам. На новом месте тоже очень интересно, думаю и здесь найду чем быть более полезным.
Вы правы, Айтишник должен нести добро и свет, а не это всё. В первую очередь я выбирал не должность, а людей с которыми придется работать. На собеседовании будущее руководство произвело на меня очень хорошее впечатление и я ни разу не пожалел о своем выборе.