При кэшировании время загрузки страницы снижается с 2 секунд до 1 секунды…
Думаю, тут спорный и очень специфичный момент. Ведь если сделать кэширование на стороне клиента, то без серверной обработки страница будет загружаться значительно быстрее. С двух секунд до одной — скорее всего при кэшировании отдельных (не всех) запросов на сервере. Есть большая вероятность, что можно еще поработать над кэшем.
более дорогие спецы по зп приходят на уровень более дешевых
Т.к. мысль о том, что более «дорогие» спецы (наверное, более опытные) вдруг потеряют опыт довольно абсурдна, буду считать, что у них падает ЗП. Но, по моим личным наблюдениям, как раз таки в первые несколько лет формирования программиста как работника, его зарплата стремительно растет. Либо он просит поднятия уровня ЗП через время (и это нормально), либо, если нет реакции руководителей, он может найти место где этот уровень получит.
В такие моменты можно понять опасения руководства, которые нанимают человека на зарплату, который всему только учится, а когда уже начинает что-то сам делать — уходит. Правда стоит отметить, что джуны в основном делают «черновую» работу.
И да, Вам уже написали, но, не знаю как у Вас в Москве, а у нас в России 50 тысяч джуну без опыта — перебор.
При определённой сноровке можно чепуху нагородить в любом языке. Другое дело, что язык с сильной типизацией, в данном примере, выдаст ошибку в рантайме, а со статической — вообще при компиляции. Правда, стоит упомянуть, что
var a = "5"+1;
тоже корректный код в C#, но только с оператором "+" и только если один из операндов — строка. Вот так уже нельзя:
int a = "5" + 1;
Т.е. всё это дело приводится к строке (toString()). Даже так можно написать:
var a = "5"+new Object();
Но это, как я полагаю, сделано для читабельного кода при конкатенации строк с «нестроками».
(В профиле написано, «можно и нужно обращаться на ты»)
Ты привязываешься к конкретному примеру? Я в целом говорю, что это возможно (как и к массиву прибавить интовую 1, и внезапно получить строковую «1»), и считаю это неправильным. Если программист действительно хочет к строке «прибавить» число, тогда он должен явно указать, он хочет получить сумму чисел или произвести конкатенацию строк (т.е. один операнд привести к типу второго).
А по поводу часто или нет. Нет, ну серьезно, скорее всего такое нечасто встречается в отполированном коде. Но в момент, когда идет действительно очень активная работа с кодом, когда над тобой давлеет дедлайн — можно по ошибке что-то не туда скопипастить, либо просто не туда вписать. Программист — не машина, иногда он теряет концентрацию и может допустить глупую ошибку. Но JS в этом случае не помогает говоря: "парень, вот тут ты уточни, ты действительно так хотел написать?". Он просто проходит некорректный участок кода, как будто так и надо, говоря: "это абсолютно не мои проблемы, я просто к пустому массиву прибавлю число, и верну строку.".
alkozko, я с Вами полностью согласен. Как и с комментариемdevalone:
А смысл этого примера? В нормальном коде этого всё равно делать никто не будет. Подобную хрень можно практически на любом языке написать, на C++ можно перегрузить оператор сложения, например.
Просто хотел подчеркнуть, что тема актуальна не только для JS. И уж точно не является руководством к действию.
Мой любимый пример, когда я начинаю объяснять, почему мне не нравится JS (и вообще слабая типизация). Это, возможно, лично мое мнение, но python (как пример динамической типизации) со своей сильной типизацией, и, как следствие, невозможностью выполнения такого кода — менее подвержен ошибкам.
private static int _a = 0;
private static int a { get => ++_a; }
static void Main(string[] args)
{
if (a == 1 && a == 2 && a == 3)
{
Console.WriteLine("True");
}
Console.Read();
}
По 7 пункту я сразу вспомнил фьюзы у микроконтроллеров AVR. Где 0 — это установлен. И можно было бы привыкнуть, но некоторые программы для прошивки инвертируют их. Что запутывает окончательно, особенно когда используешь несколько таких программ.
Еще про совместные аномалии и нейронные сети — обратите внимание на Нейронную Сеть Кохонена. Очень простая по структуре (два слоя). Легко реализуема. Обучение без учителя для этой сети тоже легче реализовать чем тот же самый алгоритм обратного распространения ошибки. Дает неплохие результаты по классификации. Правда иногда нужно поиграться с начальными весами.
… что наталкивает на мысль использовать нейронную сеть на отрендеренные графики.
По идее можно не рендерить, а просто использовать тот же персептрон. Входные данные просто нужно будет преобразовать: привести количество точек по x к количеству нейронов входного слоя, а значения y нормировать от [0, 1] либо [-1, 1].
Все 100% классов в ваших проектах имели интерфейсы?
Если взять MVC, например, то, скажем, модели (те классы, которые просто представляют сущности) — могут не использовать интерфейсы. Хотя я в моделях реализовывал интерфейсы, типа IDeletable, ISorted и подобные.
Вы лично можете не использовать интерфейсы в контроллерах, хотя опять же, зависит от ситуации, да и тот же ApiController реализует IDisposable.
Так же в C# существуют статические классы (хелперы, либо классы с расширяющими методами).
А еще вложенные типы, которые тоже, на моей практике, часто не реализуют интерфейсы.
А еще, у меня сейчас открыт проект, в котором классы Program и Startup не реализуют интерфейсы.
Это просто примеры навскидку. Уверен, найдется еще множество причин не использовать интерфейсы
И, кстати, Вам не сказал lair, что «все классы должны реализовывать интерфейсы».
Ну само рассуждение на тему «это для командной работы, а это для одиночной» — имхо, некорректны. Т.е. если программист, в начале карьеры работает сам по себе, то ему не нужно смотреть как идет разработка в корпоративных проектах? А еще сразу отбрасываем open source проекты? Или когда программист «дорастёт», то ему учиться программировать по новому?
Ну даже если он разрабатывает например сам, возьмем разработку сайтов. Вот он написал, первое что пришло в голову — логгер, который пишет лог в файл
class MyFileLogger
{
public void LogMessage(string message) {}
}
И всё у него было хорошо, пока ему не потребовалось писать лог в базу. Ему придется переписать или реализацию метода, или все ссылки на MyFileLogger исправить на MyDBLogger. А если он юзает свои наработки, возможно, что логгер в какой-то подключаемой библиотеке. Одни недостатки. То ли дело, если бы наш программист заранее подумал, «а мало ли», и сделал интерфейс:
и использовал ссылки этого типа, чтобы отвязаться от реализации.
Мой пример утрирован, но думаю, он должен дать пищу для размышлений.
Так же есть такое мнение, с которым лично я полностью согласен: «программировать нужно на уровне интерфейсов, а не на уровне реализации». Интерфейсы дают более чистое представление о структуре и логике проекта.
Конечно, я ошибся. Извиняюсь. Странный путь C# -> PHP. Хотя, конечно, я не в курсе сложившейся ситуации. При определенных обстоятельствах такой путь будет хорошим решением.
Но это не мешает применять их Вам. Хотя для меня, человека который начинал с PHP, а сейчас работающего с C#, довольно странный путь PHP->C#. Иногда, когда я касаюсь разработки на PHP, мне очень не хватает той мощности C# (особенно встроенного linq и генериков). Ну и «магичность» PHP…
P.S. Можно подумать, что я против ИИ. Наоборот, я очень интересуюсь этой темой, даже есть пара небольших репозиториев на эту тему. Я просто выражаю своё видение ситуации, и считаю, что для ИИ есть намного более интересные и важные сферы для развития.
Вы проигнорировали пример с бесплатными конструкторами сайтов.
1. Не так много осталось уникального, боюсь, что уникальное придумает «черный ящик». У нее больше данных и мыслит она иначе.
Ну тут у меня несколько замечаний. Во-первых, не так много осталось уникального — я думаю эта фраза неверна, т.к. нет границы человеческой фантазии. Во-вторых, в текущих реализациях ИИ не может придумать что-то уникальное, скажем так, в глобальном смысле. Те нейросети, которые обучаются писать стихотворения на произведениях Блока, так и будут писать стихи в этом стиле. Он даже не сможет употребить нового слова, если такового нет в лексиконе Блока. Если «мозг» машины обучают управлению по дорогам, то если его поставить на самолет, он «не поймет», что ему доступен третий угол для управления (тангаж). Если ИИ обучить на всех сайтах (сомнительное занятие, не правда ли), то он не сможет создать сайт, на котором бы при вырисовывании знака бесконечности курсором, открывалось бы диалоговое окно, предлагающее скачать последнюю студию, если такового сайта нет в сети. Я уже молчу о количестве входных/выходных нейронов для такой нейросети. А именно такие «фишки» (конечно, мой пример абсурден, первое что пришло в голову) делают разницу и привлекают посетителей на сайт.
А для каких-то совсем простых сайтов, если не хочется прибегать помощи программистов, легче воспользоваться конструкторами или там joomla-ми или что сейчас популярно.
Не согласен с Вами по поводу тупиковости WEB-разработки. Думаю, это можно сравнить с системами конструкторами сайтов. Системы появляются, рекламируются, но работы для web-разработчика/дизайнера меньше не становится.
Ну дойдут нейронные сети до того, чтобы создавать сайты по требованиям клиентов. Но рынок web-разработки вряд ли рухнет, т.к. эта сфера затрагивает не только «сайты на заказ». Некоторые крупные системы работоют с web-интерфейсом (но это, естественно, тоже про крупные компании). Да и вообще, создать какой-то действительно уникальный продукт, какой-то даже простой сайт, но с фичей, у нейросети не получится еще долго.
С другой стороны Вы правы, что всё таки веб-разработка — это в основном 95% рутины и однообразия.
Мне кажется, что при малых количествах шагов алгоритма, карта будет уж очень квадратной, что, собственно, и описано в минусах. А при больших количествах шагов — первое: тогда пропадает надобность в использовании алгоритма, если основной аргумент — скорость; второе — как я понимаю, высота будет скапливаться в нижнем правом углу карты (максимальные значения x и y). Т.е. клетки карты расположенные в этом углу будут обрабатываться чаще остальных.
Думаю, тут спорный и очень специфичный момент. Ведь если сделать кэширование на стороне клиента, то без серверной обработки страница будет загружаться значительно быстрее. С двух секунд до одной — скорее всего при кэшировании отдельных (не всех) запросов на сервере. Есть большая вероятность, что можно еще поработать над кэшем.
Т.к. мысль о том, что более «дорогие» спецы (наверное, более опытные) вдруг потеряют опыт довольно абсурдна, буду считать, что у них падает ЗП. Но, по моим личным наблюдениям, как раз таки в первые несколько лет формирования программиста как работника, его зарплата стремительно растет. Либо он просит поднятия уровня ЗП через время (и это нормально), либо, если нет реакции руководителей, он может найти место где этот уровень получит.
В такие моменты можно понять опасения руководства, которые нанимают человека на зарплату, который всему только учится, а когда уже начинает что-то сам делать — уходит. Правда стоит отметить, что джуны в основном делают «черновую» работу.
И да, Вам уже написали, но, не знаю как у Вас в Москве, а у нас в России 50 тысяч джуну без опыта — перебор.
тоже корректный код в C#, но только с оператором "+" и только если один из операндов — строка. Вот так уже нельзя:
Т.е. всё это дело приводится к строке (toString()). Даже так можно написать:
Но это, как я полагаю, сделано для читабельного кода при конкатенации строк с «нестроками».
Ты привязываешься к конкретному примеру? Я в целом говорю, что это возможно (как и к массиву прибавить интовую 1, и внезапно получить строковую «1»), и считаю это неправильным. Если программист действительно хочет к строке «прибавить» число, тогда он должен явно указать, он хочет получить сумму чисел или произвести конкатенацию строк (т.е. один операнд привести к типу второго).
А по поводу часто или нет. Нет, ну серьезно, скорее всего такое нечасто встречается в отполированном коде. Но в момент, когда идет действительно очень активная работа с кодом, когда над тобой давлеет дедлайн — можно по ошибке что-то не туда скопипастить, либо просто не туда вписать. Программист — не машина, иногда он теряет концентрацию и может допустить глупую ошибку. Но JS в этом случае не помогает говоря: "парень, вот тут ты уточни, ты действительно так хотел написать?". Он просто проходит некорректный участок кода, как будто так и надо, говоря: "это абсолютно не мои проблемы, я просто к пустому массиву прибавлю число, и верну строку.".
Просто хотел подчеркнуть, что тема актуальна не только для JS. И уж точно не является руководством к действию.
По 7 пункту я сразу вспомнил фьюзы у микроконтроллеров AVR. Где 0 — это установлен. И можно было бы привыкнуть, но некоторые программы для прошивки инвертируют их. Что запутывает окончательно, особенно когда используешь несколько таких программ.
По идее можно не рендерить, а просто использовать тот же персептрон. Входные данные просто нужно будет преобразовать: привести количество точек по x к количеству нейронов входного слоя, а значения y нормировать от [0, 1] либо [-1, 1].
Если взять MVC, например, то, скажем, модели (те классы, которые просто представляют сущности) — могут не использовать интерфейсы. Хотя я в моделях реализовывал интерфейсы, типа IDeletable, ISorted и подобные.
Вы лично можете не использовать интерфейсы в контроллерах, хотя опять же, зависит от ситуации, да и тот же ApiController реализует IDisposable.
Так же в C# существуют статические классы (хелперы, либо классы с расширяющими методами).
А еще вложенные типы, которые тоже, на моей практике, часто не реализуют интерфейсы.
А еще, у меня сейчас открыт проект, в котором классы Program и Startup не реализуют интерфейсы.
Это просто примеры навскидку. Уверен, найдется еще множество причин не использовать интерфейсы
И, кстати, Вам не сказал lair, что «все классы должны реализовывать интерфейсы».
Ну даже если он разрабатывает например сам, возьмем разработку сайтов. Вот он написал, первое что пришло в голову — логгер, который пишет лог в файл
И всё у него было хорошо, пока ему не потребовалось писать лог в базу. Ему придется переписать или реализацию метода, или все ссылки на MyFileLogger исправить на MyDBLogger. А если он юзает свои наработки, возможно, что логгер в какой-то подключаемой библиотеке. Одни недостатки. То ли дело, если бы наш программист заранее подумал, «а мало ли», и сделал интерфейс:
и использовал ссылки этого типа, чтобы отвязаться от реализации.
Мой пример утрирован, но думаю, он должен дать пищу для размышлений.
Так же есть такое мнение, с которым лично я полностью согласен: «программировать нужно на уровне интерфейсов, а не на уровне реализации». Интерфейсы дают более чистое представление о структуре и логике проекта.
Ну тут у меня несколько замечаний. Во-первых, не так много осталось уникального — я думаю эта фраза неверна, т.к. нет границы человеческой фантазии. Во-вторых, в текущих реализациях ИИ не может придумать что-то уникальное, скажем так, в глобальном смысле. Те нейросети, которые обучаются писать стихотворения на произведениях Блока, так и будут писать стихи в этом стиле. Он даже не сможет употребить нового слова, если такового нет в лексиконе Блока. Если «мозг» машины обучают управлению по дорогам, то если его поставить на самолет, он «не поймет», что ему доступен третий угол для управления (тангаж). Если ИИ обучить на всех сайтах (сомнительное занятие, не правда ли), то он не сможет создать сайт, на котором бы при вырисовывании знака бесконечности курсором, открывалось бы диалоговое окно, предлагающее скачать последнюю студию, если такового сайта нет в сети. Я уже молчу о количестве входных/выходных нейронов для такой нейросети. А именно такие «фишки» (конечно, мой пример абсурден, первое что пришло в голову) делают разницу и привлекают посетителей на сайт.
А для каких-то совсем простых сайтов, если не хочется прибегать помощи программистов, легче воспользоваться конструкторами или там joomla-ми или что сейчас популярно.
Ну дойдут нейронные сети до того, чтобы создавать сайты по требованиям клиентов. Но рынок web-разработки вряд ли рухнет, т.к. эта сфера затрагивает не только «сайты на заказ». Некоторые крупные системы работоют с web-интерфейсом (но это, естественно, тоже про крупные компании). Да и вообще, создать какой-то действительно уникальный продукт, какой-то даже простой сайт, но с фичей, у нейросети не получится еще долго.
С другой стороны Вы правы, что всё таки веб-разработка — это в основном 95% рутины и однообразия.