• Старт в бэкенд-разработке (Python). Можно ли обойтись без знания фронтенд-технологий?

    @0x131315
    Конечно можно.
    Совсем без фронта обойтись скорее всего не выйдет - много где на банке лежит html и js, и поправить что-то самому намного быстрее, чем объяснить задачу фронтендеру.
    Но верстать не обязательно.
    Много задач чисто по бекенду, часто очень сложные, требующие именно специалиста. Работа с БД, бизнес-логика, общий код - все это чисто бекенд.
    Ответ написан
    Комментировать
  • MySQL+PHP и компилируемый язык?

    @0x131315
    Исходя из описания, будет большая БД и простенький клиент для неё.
    Основные требования - именно к БД: распределенность, отказоустойчивость, расширяемость.
    С первыми двумя всё просто: кластер.
    А вот расширяемость напрямую зависит от архитектуры БД - над ней стоит поработать как следует, потом что-то исправить здесь будет очень сложно и дорого.
    С кривой архитектурой не поможет ни кластер, ни оптимальный код клиента - БД будет тормозить всегда, проект придется свернуть.
    Так что всё правильно сказали - язык не столь важен, как БД. Клиентов можно наделать сколько угодно, и на любых языках - клиенты примитивные.
    А вот бизнес-логика, если она есть - её поддерживать на нескольких языках дорого. Если она есть - нужно под неё выбрать один язык, и писать всё на нем.
    Сейчас для такого в ходу go, python и php. Выбирать лучше то, что знаешь - масштабировать под нагрузку всё это можно легко.
    Для клиентов на этом языке делается api, за которым скрывается бизнес-логика.
    В таком варианте код клиентов простой и дешёвый, логика поддерживается в одном варианте, и всегда согласованна со всеми клиентами.
    Ответ написан
  • Как все-таки правильно разделять back-end от front-end?

    @0x131315
    По возможности стоит следовать принципу MVC, разделяя код на слой данных, слой логики и слой отрисовки - это сгруппирует однотипный код, и сильно упростит его поддержку.
    Специфичные вещи, например работу с внешним API, следует оформлять в отдельные классы, модули, хэлперы - это облегчит работу с такими вещами, упростит отладку (сам класс можно протестировать отдельно), сгруппирует код: код, отвечающий за конкретное API, весь в одном месте. И когда этот код понадобится вновь - всё уже готово и отлажено, подключи класс и пользуйся.
    Сразу весь функционал реализовывать не нужно - по мере надобности недостающее допишется. В крайнем случае можно набросать заглушки (пустые методы) для чего-то, что должно быть, но пока не нужно.

    Что касается конкретно отрисовки - да, активное использование ajax и реактивных фреймворков серьезно улучшает приложении: гораздо проще реализовывать странички со сложным поведением, не нужно перерисовывать куски страниц, думать как разбить и обновить контент, просто отдаёшь данные, шаблон, и фреймворк сам перерисовывает нужные части.
    Но что-то простое гораздо быстрее отрендерить на сервере, просто вставив в нужные места верстки php-код. Плюс серверный рендеринг скрывает промежуточные данные - в страничку вшивается только результат вычислений, и у пользователя нет никаких способов получить промежуточные данные, или даже узнать о том, что они существуют.
    Так что для простых или важных вещей стоит пользоваться php, для сложных - отдавать данные по ajax, отрисовывать их на клиенте, а для неответственных данных можно даже вычисления перенести на клиент, но стоит помнить, что js немного неожиданно работает с некоторыми вещами: приведение типов, время, математика, числа с плавающей точкой.
    Как промежуточный вариант можно пользоваться шаблонизаторами - с ними в несколько раз быстрее раскидать данные по шаблону, чем на чистом php, и код получается чище, но для сложного поведения все равно лучше реактивный фреймворк.
    Ответ написан
    1 комментарий
  • Как преодолеть кризис начинающего специалиста?

    @0x131315
    Да, программист - не так романтично на деле, как кажется)
    Потому что, в отличии от всяких мечтаний, в реале вопрос завязан на деньги, а деньги - на время.
    Программист работает на заказчика, заказчику нужно быстро и дешево - отсюда готовые решения и костыли сейчас, с прицелом разобрать это потом (но потом тоже костыли)
    Поначалу все это очень напрягает и срывает башню - нас учили не такому, нас учили стремиться к простому и оптимальному коду, а везде вокруг накручивают дичайшие костыли, и это жесть, но...
    Со временем понимаешь, что лучше сейчас быстро сделать костыль, и забыть об этом, возможно навсегда, чем потратить времени в 3-4 раза больше, но сделать по канонам... Просто у программиста нет столько времени...
    В конце концов в реальности работа программиста не так сложна, и во многом не так красива, как ожидается - по большей части это рутина и разгребание чужого страшного кода, отладка и ваяние своего страшного кода, сожаление о том, что не было возможности сделать хорошо, и радость, когда попадается что-то интересное, или то, что сделал хорошо, качественно
    Как и на любой работе, есть свои светлые и темные стороны. И деньги не так легко достаются - программист за них щедро платит нервами. Как и врач, и любой другой специалист
    Ответ написан
    1 комментарий
  • Как научить ботов учитывать гравитацию планеты при стрельбе?

    @0x131315
    По поводу скрипта - он странный:
    1) Он работает только для обьектов, которые участвуют в столкновениях.
    2) Он не учитывает дистанцию до центрального тела, только его массу, и работает только для случаев, когда дистанция между противниками в тысячи раз меньше дистанции до центрального тела, т.е. более-менее точен где-то на задворках звездной системы, вдали от звезды. На более ближних дистанциях начинает безбожно врать.
    3) Он наполняет обьектами массив, который не особо нужен скрипту для работы, который нигде не очищается. Это - утечка памяти.
    4) Его можно прикладывать только к одному телу - центральному. Иначе это умножает утечку памяти и сильно расходует процессор. В некоторых случаях его можно заменить триггером. И часто его оптимизируют, вызывая раз в несколько десятков кадров, а не каждый кадр. Также пишут, что указание маски слоя в Physics.OverlapSphere повышает эффективность работы.

    По поводу утечки.
    Не знаю тонкостей unity, не могу сказать точно, насколько она серьезна. Но возможны два варианта:
    1) обьект скрипта пересоздается каждый кадр, и время от времени устаревшие экземпляры собирает сборщик мусора.
    Тогда утечка равна размеру массива помноженному на количество кадров в секунду и на таймаут сборщика мусора.
    При условии, что скрипт используется только на одном обьекте (надеюсь ты не додумался применить его ко всем обьектам?), для 1000 обьектов в сцене, 60фпс и 10 секундном таймауте сборщика мусора, утечка составит 5..50Мб - именно столько памяти игра будет отьедать впустую, никуда не используя, только на один экземпляр этого скрипта.
    Если скрипт применен к 10 обьектам, утечка увеличится до 50..500Мб.
    А если обьектов 1000?
    Так и рождаются игры, которые требуют 16Гб оперативки.
    Это не говоря о бесполезной трате процессорных ресурсов: если по глупости применить скрипт ко всем обьектам, эффективно работать он будет только на одном, но жрать память и процессор будет за всех.
    На 1000 обьектах потребление процессора этим скриптом увеличится в 1000000 раз: 1000 скриптов должны будут каждый обработать по 1000 обьектов.
    Так рождаются игры, которые требуют топовое железо.
    Всего 2 легкие ошибки с одним скриптом (далеко не основным) - и такой потенциал! :)
    2) Используется один экземпляр скрипта, он не пересоздается каждый вызов.
    Тогда обьем массива каждую секунду умножается на фпс, пока массив не забьет всю память.
    И сборщик мусора тут не поможет, т.к. скрипт существует пока существует основной обьект, т.е. пока загружен уровень - всю игровую сессию.
    Для тех же условий утечка в первую секунду составит 0,5..5Мб, и каждую секунду будет увеличиваться на столько же. За час игры утечка составит от 2 до 20Гб, в зависимости от размера структур.
    Утечка процессора останется той же, что и в первом варианте.

    Твой вариант походу первый, иначе бы скрипт отработал ровно один раз, и гравитация после первого кадра пропала: массив используется для проверки тел, к которым еще не прикладывалась гравитация.
    А это не так - раз есть постоянная ошибка, гравитация работает дольше одного кадра.
    Кстати, проверка эта лишняя, в документации ее нет.

    По поводу ошибок прицеливания: введи поправки на гравитацию при прицеливании.
    Не факт, что это тебе поможет, все-таки скрипт у тебя кривой, и непонятно правильно ли ты его используешь - каковы максимальные дистанции между противниками, каковы минимальные дистанции от противников до центрального тела, каков размер центрального тела, как создаются снаряды (независимыми или привязанными к тому, кто выстрелил), как задается их скорость (постоянная или относительно скорости выстрелившего), какова скорость снаряда и цели.
    Но самое простое:
    dy=g*t*t/2
    t=l/v
    dy - величина смещения снаряда гравитацией на текущей дистанции
    g - величина гравитации, локальная (вблизи точки выстрела). В твоем скрипте гравитация постоянна, не зависит от координат, и равна массе центрального тела, значит вместо g можно подставить массу центрального тела.
    t - время полета снаряда
    l - прямая дистанция до противника.
    v - глобальная скорость снаряда (относительно мира).
    Ограничения:
    Локальная гравитация неприменима, если дистанция сравнима с расстоянием до центрального тела - там нужен дополнительный учет кривизны поля гравитации. Гравитация в разных точках пути снаряда будет разная, а это сильно снизит точность, особенно на больших дистанциях - на много порядков.
    Прямая дистанция неприменима, если дистанция сравнима с расстоянием до центрального тела - там нужен дополнительный учет кривизны поля гравитации. Дистанция будет не прямой, а дугой, и значит снаряд пройдет больше расстояния, лететь будет дольше, и поправка нужна больше.
    Если время полета больше нескольких секунд, придется учитывать влияние гравитации на скорость снаряда. Снаряд будет ускоряться или замедляться гравитацией, а значит точность с дистанцией начнет быстро падать.
    Если скорость цели сравнима со скоростью снаряда - придется учитывать, что цель движется. Пока снаряд летит в точку прицеливания, быстрая цель оттуда уже убежит, и точность никакой не будет.
    Ответ написан
    1 комментарий
  • Как научиться быстро читать?

    @0x131315
    Много читать - это понятно. В свое время тоже ставил рекорды, проглатывая по 400 страниц за ночь, чересчур увлекшись.
    Но скорочтение не о том, как много читать, а о том, как читать максимально быстро.

    Сейчас например могу читать пару раз в неделю, страниц по 50-100 за раз - это 2-4 часа в неделю. Свободного времени конечно гораздо больше, но его поглощают всякие дела и заботы, отдых и развлечения, отсутствие настроения.
    Средняя книжка страниц на 800 такими темпами занимает месяц-два. Раньше это было несколько дней-неделя. Грустно, хочется прочитать гораздо больше, чем можешь себе позволить.
    А вот времени осмыслить прочитанное намного больше, по нескольку часов в день - когда сознание ничем не занято, и можно подумать о чем-нибудь, поразмышлять.

    Т.е. проблема в том, что времени читать много, но мало времени когда есть возможность читать. Так что требуется как-то загрузить книгу в память, и читать уже оттуда.
    Смарты и читалки тут не помощники - в такие моменты, когда можешь и хочешь читать, по той или иной причине часто не удобно утыкаться в экран - приходится довольствоваться собственной памятью.
    Читаю эти 50-100 страниц за раз именно со смарта - он удобнее компа, за счет мобильности: читай где удобно.
    Но когда требуется читать много - пользуюсь компом, на нем гораздо комфортнее читать много, сидя в кресле: во первых в такой позе в сон не клонит (извечная проблема со смартом - как только голова подушки касается, быстро засыпаешь, не успевая много прочитать), во вторых такую позу удобно сохранять длительное время, ну и руки свободны заниматься чем-нибудь еще.

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

    Методика специально выдерживает высокую скорость смены слов - чтобы ты даже не пытался читать текст.
    По началу трудно: читаешь одно слово из десяти,выхватывая из потока, ни о каком смысле не может быть и речи.
    Это может заставить бросить, т.к. сразу результатов нет. Но тут главное не бросать попыток: мозг - удивительная машина, и очень быстро адаптируется к новой задаче.
    У меня это заняло где-то полчаса упорных попыток поспеть за скоростью текста, читая с экрана. Далось это тяжело, т.к. нужно сохранять предельный уровень концентрации.
    Но как только ты сдашься и перестанешь пытаться читать текст, наступает прозрение: ты читаешь не читая!
    Процент прочитанных слов резко подскакивает: оказывается так читать даже удобнее.
    С практикой процент ошибок быстро падает.
    Ощущения в этот момент необычные - чтение без чтения. Потом привыкаешь.

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

    Но на этой методике можно научиться читать текст из картинок, которые лежат в кратковременной памяти. Это не сложно.
    Если что-то не понял - "снятая" картинка доступна в течении нескольких секунд, можно к ней вернуться и перечитать (я иногда и по 2-3 раза перечитываю, но за время жизни картинки в кратковременной памяти легко можно и 20-30 раз перечитать), причем это в то время, как "фотографируешь" глазами другие картинки, параллельно.

    Т.е. скорость анализа картинок в памяти намного выше скорости обычного чтения глазами, а скорость фотографирования - намного выше скорости анализа.
    Выгоднее фотографировать текст с предельной скоростью, потом по быстрому его анализировать в фоне, а читать уже позже, из памяти, когда будет время.
    Это выгоднее и по скорости, и по времени: обычно 80% времени нет доступа к книге/источнику, либо нет возможности читать его. За те 20% времени нужно как можно быстрее перегнать книгу в память, а читать ее в оставшиеся 80% времени, как удобно. Превращаешься в своего рода флешку.

    Отсюда идея: а что если не читать текст, а просто фотографировать?
    Прочитать его можно потом, и намного быстрее, чем обычно.
    Предельная физическая скорость фотографирования - 1/2 взгляда на страницу, 200 кадров в секунду, т.е. до 400 стр/с.
    Реальная, понятно, намного ниже - как успеваешь листать страницы, да и взглядом нужно их хотя бы окинуть, иначе не вспомнишь ничего (поле зрения у глаза очень узкое, им нужно сканировать страницу). Вероятно около 2-4 стр/с, но это все-равно намного выше скорости чтения.

    Минус только один: нужна тренированная память.
    Но что если тренировать ее прямо на практике?

    Как я это вижу:
    Сначала тренируемся на кошках - на видео, потом переходим на программы, нарезающие текст на слова и выводящие на экран, как в видео, в это время тренируемся читать и перечитывать текст из кратковременной памяти, а не с экрана, снижаем процент ошибок.
    Потом учимся нарезать текст обычных книг на слова мысленно или взглядом. Про костыли забываем как про страшный сон.
    Потом тренируемся расширяя поле зрения, захватывая не по одному слову за раз, а по два, три, и т.д. на картинку.
    Потом переходим к тренировке визуальной памяти: пытаемся сложные вещи анализировать после прочтения, запоминая вначале их описания, а позже - только картинки текста. Это может занять месяцы.
    Потом переходим к формулам и графике - это сложнее, но и сильнее тренирует память. Пытаемся анализировать формулы/картинки после прочтения, при прочтении вначале запоминая их описания, а позже - только картинки участка страницы с ними. Опять же понадобится несколько месяцев практики, чтобы память подтянулась до такого уровня.
    Ну а потом непосредственно тренируем фотографирование: пытаемся запоминать целые страницы. Это уже на годы практики тянет - целую страницу запомнить сложнее. Но возможно, и со временем начнет получаться непроизвольно.
    Потом неизбежно приходим к менеджменту памяти и технологиям сжатия информации: запомненную книжку легко потерять в памяти, если ее не прочитать вскоре после запоминания, эту книжку в памяти нужно куда-то положить, с чем-то связать, чтобы потом можно было найти сознательно, ну и когда книжек много - нужно как-то выделять из них актуальные куски информации, не удерживая в памяти весь текст.

    В общем изначально концентрируемся на визуальной памяти, и со временем просто расширяем ее возможности, практикуя чтение - она сама должна тренироваться.
    Главное - не прерывать практику, иначе скатимся к началу. Как и в любом другом деле.
    Ответ написан
    2 комментария
  • Раньше uTorrent мгновенно хешировал даже раздачи по 250 Гб, а сейчас по 10 минут хеширует 3 Гб. Что случилось?

    @0x131315
    В бородатые годы у DC++ была замечательная опция - сохранять хэши файлов в их файловых потоках. Вот тогда все хэшировалось мгновенно, за счет того, что вместо файла можно было прочитать уже предвычесленный ранее хэш.
    Для торрент-клиентов это не имеет особого смысла - там хэширование нужно в основном для проверки целостности, а значит так и так нужно читать весь файл.

    Хэширование всегда идет на максимальной скорости, т.е. забивает i/o диска по чтению на 100%. Т.к. для процессора 50-500мб/с файлового потока вообще незаметны, и он никак это дело не ограничивает.
    Так что если низкая скорость хэширования - в первую очередь нужно провести линейный тест чтения диска. Может он умирает?

    Если кэш маленький - хэширование может делить доступ к диску с закачками/раздачами, замедляясь в 3-4 раза, но только на hdd. На ssd подобное незаметно в принципе.
    Решение - выставить авторазмер кэшу, либо увеличить кэш, если он не резиновый (постоянного размера), и отключить принудительный сброс кэша на диск (задача кэша - отложить запись как можно дольше), иначе каждый законченный блок будет прерывать хэширование на время записи, а при 100мбит/с потоке, 4кб блоках и hdd - это загрузка i/o потоком записи от 25 до 100%.

    С торрентами и виндой есть еще один прикол: большая степень фрагментации. При неверных настройках (а это 95% пользователей), забитом диске (наличие микроокон из свободных кластеров) и неумении нормально распределять место под файлы (а это все версии винды) на выходе получаем чудовищную фрагментацию: 30-50к фрагментов на 4гб образ - это норма.
    Такая сильная фрагментация замедляет чтение, очень сильно на hdd, и заметно на ssd: даже у ssd есть ограничение по iops, и оно не такое уж и большое, разница по времени чтения может достигать 200% на ssd и over 9000% на hdd.
    Так что медленное хэширование - это еще и сигнал проверить уровень фрагментации интересующих файлов. Если он высокий - следует устранить фрагментацию (даже на ssd!), и перенастроить торрент-клиент правильно.

    Ну и для десятки в частности характерен баг с медленным доступом к файлам. Сообщения об этом в сети есть. Не знаю почему, но 10-ка получилась медленнее 7-ки и 8-ки.
    Решения нет.

    Плюс на все это может наложиться проблема с кешами.
    Во всех торрент-клиентах системный кэш нужно вырубать - не умеют операционки работать с торрентами, не различают контекст, начинают грузить файлы по их запросам в память без разбора, чем вызывают ненужный оверхэд.
    Если в десятке наворотили с подсистемой кэширования - это могло дополнительно усугубить, не такой уж и заметный на других версиях винды, оверхэд.
    Решение - выключить ОС из работы, установив соответствующие опции в настройках клиента.
    Ответ написан
    1 комментарий
  • Почему после использования Auslogics Disk Defrag уменьшается свободное место?

    @0x131315
    Тут Дефрагментатор — встроенный или сторонний? хорошо ответили, почему штатного хватает.
    Ответ написан
    Комментировать
  • AdBlock зачем ты так?

    @0x131315
    Нейросеть не спасет, например моя нейросеть этот текст все-равно относит к рекламным:
    ->Работаем от производителя
    ->Пиломатериалы всегда в наличии
    ->Магазин и склад в одном месте
    ->Помощь в организации доставки
    Что это, как не реклама? Зачем мне это читать? Пустая информация, лишняя, следует сокрыть.
    Ответ написан
  • Как решить проблему с приоритетом IPv6 над IPv4 на некоторых HTTPS-ресурсах, в частности, habracdn.net?

    @0x131315
    Я смотрю адрес нужного по ipv4 сайта здесь chrome://net-internals/#dns
    И далее заношу его диапазон /32 сюда: superuser.com/questions/436574/ipv4-vs-ipv6-priori...
    Для линукса https://version6.ru/deprefer-ipv6
    Ну и так до кучи drtr0jan.livejournal.com/229199.html
    Для хрома поставил плагин ipvfoo, чтобы наблюдать через что зашел.

    Это помогло в частности гонять ютуб через ipv4, где он быстрее.
    Ответ написан
    1 комментарий
  • Замедляет ли работу компьютера размещение на рабочем столе папок с тяжелым содержимым (от 1 Гб и выше)?

    @0x131315
    По субьективным ощущениям (тестов не проводил) на скорость работы компа влияет количество обьектов в папке профиля, в т.ч. в документах и на рабочем столе.
    Именно количество, а не размер: если так нужен мусор на рабочем столе, лучше упаковать мусор в архивы, а ярлыки - рассовать по папкам. Так будет все работать гораздо быстрее.

    Виновата тут скорее всего ФС. Кто работал с большим количеством обьектов, наверняка замечал, что в папке могут быть сотни тысяч обьектов, и они никак не проявляют себя, пока не откроешь папку - вот тогда начинаются адские тормоза.
    Т.е. виновато то, что профиль постоянно открыт (системой и многими приложениями), и туда очень часто идут обращения, так что размещение там лишнего крайне не рекомендуется.
    А причина тормозов, в т.ч. с папками на рабочем столе, ярлыками, и Пуском - не количество памяти, а обращения к диску.
    При обновлении рабочего стола система вынуждена переоткрыть каждый ярлык, т.е. скачать с диска и распарсить каждый файл ярлыка, найти и подгрузить к нему иконки, открыть папку, на которую ссылается ярлык (а это генерит еще один шквал обращений к ФС), проверить ссылки на запускаемые файлы, и кто знает что еще. И так для каждого ярлыка.
    Если на рабочем столе лежат папки - ситуация еще хуже: для каждой папки система должна отрисовать значок содержимого, для этого она открывает папку, и проверяет каждый файл в ней, и если находит медиафайлы - парсит их, генерит иконку, потом выбирает несколько иконок, и из них генерит иконку папки. При этом внутрь подпапок она не заглядывает. Поэтому простое рассовывание мусора по папкам спасает - даже если обращение будет в папку, где лежал мусор, подпапку с мусором никто сканировать не будет, а значит и мусор останется нетронут, и эти сотни тысяч файлов никак не затормозят систему.

    И все это относится не только к рабочему столу - а вообще к любым видимым папкам и файлам в проводнике, и к тем, куда обращаются разные программы (всякие документы, local, и т.п. проходные папки, гуда суется каждая прога).
    Поэтому так популярны альтернативные ФМ, которые не страдают подобной фигней, не генерят тонны запросов к диску ради украшательства.

    Незаметно все это может быть, только если у вас SSD. Но незаметно - не значит хорошо: пусть все-это сьедает небольшую часть i/o SSD, но тем не менее сьедает, и бесполезно - лучше оставить эти ресурсы другим приложениям, тем более производительность SSD на таких мелких операциях очень и очень конечна, порядка 50-70Мб/с, и ее легко выжрать.

    Ситуацию осложняет NTFS - при каждом обращения к файлу она переписывает его аттрибуты (время последнего доступа), и тут же скидывает их на диск (синхронная запись, в обход буферов), это сьедает до половины скорости диска. Эту фичу можно выключить, и значительно облегчить жизнь диску. Да и SSD не к чему постоянная перезапись MFT.

    Ну и как бонусом, поверх всего этого цирка сидит служба индексации, и постоянно мониторит системный диск, генерируя лишние запросы. Ее тоже лучше убить, а для поиска использовать более быстрые инструменты, вроде Everything или SwiftSearch.
    Ответ написан
    1 комментарий
  • Как уйти с распутья технологий?

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

    Что касается языка - на первое время следует сосредоточится на чем-то популярном, попсовом, где больше всего вакансий, где проще найти работу. На зарплаты пока внимания обращать смысла нет - это лишь первый шаг, потом все-равно зарплаты станут больше, и скорее всего сменишь сферу деятельности, в соответствии со своими вкусами и желаниями.
    Но чтобы получить время на изучение языка, требуется источник дохода - любая работа, которая позволит кушать, платить за квартиру, одежду, оборудование и услуги.

    А так по моему важнее не инструмент, а умение им пользоваться. Начинать следует с алгоритмов, а язык использовать как инструмент.
    Хотя откладывать изучение языка тоже нельзя - практика важнее теории. Так что в комплексе - постигай алгоритмы на практике, по мере необходимости, и запоминай их.

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

    Конкретный язык нужен кодерам - это те, кто воплощает чужие идеи в коде, т.е. конечные винтики в процессе разработки софта, исполнители. От кодеров требуется только перенести уже готовый алгоритм на требуемый язык, максимально быстро, и по возможности без ошибок.
    Изучив конкретный язык ты можешь стать кодером, но это черновая работа, и по хорошему - временная, просто ступенька на пути становления программиста. Нужно двигаться к архитектору, инженеру, непосредственно программисту в широком смысле.

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

    Также упрощает задачу стандартизация подходов к решению задач, парадигм - большинство из них уже формализованы, и описаны. Например всем известное ООП, модульное программирование, конечные автоматы, и т.п. Описано более двух десятков таких моделей, их следует по возможности освоить. И не стесняться комбинировать.

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

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

    Но все-равно, даже программисту нужен опыт. Не важно что он отвязан от языков - он все-таки привязан к одному языку, информации, и должен уметь с ней обращаться.
    Опыт экономит время и усилия - там, где сперва требовалось неделю гуглить и пробовать, потом, с опытом, все делаешь за час, просто уже понимая что, как, когда и зачем.

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

    Главное найти задачу и решить ее. Начинаешь с простых, и постепенно усложняешь. Параллельно, прямо по ходу решения, изучаешь алгоритмы, и нарабатываешь опыт. Со временем начнешь щелкать задачи быстро и между делом, как семечки, те, которые по первости у тебя отнимали недели, а то и месяцы.

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

    С третьим - придешь, когда поймешь, что тебе это нужно. Из-под палки не учатся.

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

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

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

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

    Сложность задачи не особо влияет на мотивацию, а вот факт решения/нерешения - влияет сильно. Не решил - значит не осилил, не осилил - значит не достоин, не достоин - значит иди ко дну и не рыпайся. Это как импотенция: импотент - значит не мужик, не мужик - значит никто, ничего не достоин и об тебя можно ноги вытирать. Подсознание портит всю малину, так что не следует давать ему шанса - лучше решить задачу попроще, чем не решить по сложнее.
    Ответ написан
    7 комментариев
  • Существуют ли OpenSource нейросети по работе с текстом и общением?

    @0x131315
    Нейросеть не работает с текстом. Она работает с данными, а уж какие данные - это как обучишь.

    Тебе нужен OpenSource framework для построения нейросетей. Далее строишь нейросеть, и обучаешь.

    Нейросети не самообучаются и очень ограничены. Их требуется обучать извне.
    Их необходимо тренировать в контролируемых условиях, и далее фиксировать, запрещать развитие. Так обычно и делают.
    Именно такие обученные и зафиксированые сети и представляют коммерческую ценность, являясь законченным продуктом. Нефиксированных сетей боятся как огня - они склонны выкидывать сюрпризы.

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

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

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

    В общем технология примитивная: эволюция и есть эволюция, ты просто определяешь критерии успешности, по которым отделяешь успешные вариации от негодных, и далее фиксируешь положительные изменения, а негативные отбрасываешь.
    Методы обучения можешь погуглить - их несколько, и все они старые.
    Ответ написан
    3 комментария
  • Действительно ли важно правильное питание для мозга программиста (с точки зрения науки)?

    @0x131315
    Интеллектуальным спецам нужно не только правильно питаться, но и правильно жить:
    1 - шум отвлекает, "выключает" мозг. Шум - это радио, телевизор, и родня.
    Нужна отдельная комната, желательна отдельная хата.
    Дети в доме - конец работе, комната не спасет.
    Единственное тихое время - ночь, но она слишком коротка.
    2 - без четкого распорядка дня работа неэффективна, без распорядка внимание с удовольствием поглощают всякие "срочные" дела, мозг ищет любую возможность убежать от работы. С точки зрения эволюции и выживания - работа мозга самая тяжелая по ресурсам организма, вот организм и пытается эти ресурсы экономить, выключая мозг. Сюда же относятся раздражители и рассеиватели внимания - интернет, телефон, родственники.
    Можно тренировать силу воли, но проще приучить себя к определенному порядку действий, например в рабочие часы блокировать средства связи: смарты в беззвучный режим и с глаз долой, роутер режет все, кроме справочных сайтов, справочные сайты можно заменить оффлайн-книжкой. В общем стараться выводить себя в оффлайн. Ночные часы почти автоматом оффлайновые - никто не побеспокоит.
    3 - когда работаешь головой, требуется постоянно учиться, но к концу рабочего дня мозг "протухает", так что учиться нужно в первой половине дня.

    По питанию:
    Заметил, что чувствую себя гораздо лучше, если не ем сахар, мясо, жирное, и не злоупотребляю водой, и вообще немножко голодую.
    Впрочем, когда чем-то увлечен, голодуешь автоматом - тупо забываешь покушать. Но если совсем не есть - быстро теряешь силы, быстро выдыхаешься, появляется слабость, истощение. В общем еда в прямом смысле заряжает.
    В то же время если пить слишком мало, или слишком много, есть плотно, обильно, употреблять много сладкого и жирного - обязательно будет хуже, сразу или отложено, в течении нескольких дней.
    Вода с жиром вообще не сочетаются: если ты имеешь лишний жирок, излишек воды тебя "раздует" как бегемота, заметно увеличив обьемы жирка, зато когда вода выйдет (а выходит она быстро, в течении 2-3 дней) - также быстро "похудеешь". Так что жир - настоящая подкожная емкость, способная питать водой в течении нескольких суток напрямую, и еще несколько суток - по мере выгорания жира.
    Таким образом нужно есть и пить чуть больше минимально необходимого уровня.
    На счет худобы - слишком много жира в теле это плохо, и болезни всякие, и просто тяжело, но в то же время жир - отличный источник энергии, и когда надо много работать, но кушать нечего/забываешь - жир желателен.

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

    Вообще с энергоснабжением организма все очень забавно: нативное топливо клеток, в которое конвертируются все другие топлива - молекулы АТФ, это что-то вроде маленьких химических батареек, весь организм пропитан этим веществом, но мгновенная масса его ничтожна - около 250гр. Фокус в том, что эти батарейки производятся организмом в огромных количествах, и тут же потребляются. В магазинах продают порошок АТФ для спортсменов, рекомендуют принимать по полграмма в сутки - это на самом деле звучит смешно, если учесть, что в сутки организм производит около 40кг(!) АТФ (и тут же их поглощает) - эти полграмма погоды не сделают никак. Избыток в 250гр - это именно что оперативный (АТФ - "мгновенное" топливо, может потребляться сразу по потребности) резерв, как конденсатор, на случай если возникнет скачок энергопотребления: пока будет расходоваться этот резерв, в работу успеют включится дополнительные механизмы синтеза. А этих механизмов у нас много.

    Главный цикл энергообмена: АДФ + фосфорная кислота + энергия <=> АТФ + вода.
    Т.е. цикл замкнутый: сколько поглотилось, столько и выделилось. Но можно заметить, что без фосфора и воды процесс не идет.
    Фосфор - в рыбе, значит нужна рыба в рационе, и побольше: мозг требует активного энергообмена.

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

    Основные механизмы синтеза АТФ:
    1 - гликолиз: С6Н12О6(глюкоза) + 2Н3РО4 + 2АДФ = 2С3Н4О3(ПВК) + 2АТФ + 2Н2О. Для превращения сахара/углеводов в глюкозу нужен инсулин, который синтезирует поджелудочная.
    ПВК в мышцах превращается в муравьиную кислоту - та, что вызывает жжение в мышцах.
    2 - кислородный гликолиз: 2С3Н6О3(молочн.кислота) + 6О2 + 36Н3РО4 + 36АДФ = 6СО2 + 42Н2О + 36АТФ
    3 - расщепление жиров, липолиз - дает много тепла, выделяется 131АТФ и много воды. Инсулин тормозит липолиз - глюкоза не дает сжигать жиры. Жировой реактор позволяет греться зимой, и "пить" без воды - поэтому мишки набирают жирок перед спячкой, для отопления, а верблюды запасают жир в горбах - чтобы пить.

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

    Для того, чтобы увеличить подачу энергии в мозг в 20 раз, нужно сьесть углеводов(сахара например), поработать мышцами и активно дышать (ага, секас считается).
    Для того, чтобы увеличить подачу энергии в мозг в 65 раз, нужно наличие жира в организме (в принципе обычное питание и так обеспечивает до 100гр жира в сутки, так что всегда есть что сжигать) и час физ.нагрузки на воздухе (требуется очень много кислорода), отсутствие инсулина: после тренировки 2 часа ничего не есть и 12 часов не потреблять углеводов, можно потреблять только продукты с низким гликемическим индексом, иначе углеводы запустят синтез инсулина, который погасит липолиз.

    Таким образом главных источника энергии два: кислородный гликолиз и липолиз.
    Гликолиз - "быстрый", запускается сразу, как начинается работа в мышцах.
    Липолиз - "медленный", но чрезвычайно мощный, разжигается час, зато горит 12 часов, и обеспечивает вчетверо большую мощность, чем первый - позволяет переносить большие нагрузки, и переносить долго.

    Оба источника взаимоисключающие: пока есть глюкоза - липолиз не запустится, когда запущен липолиз - нельзя есть углеводы.
    Зная это, можно "профилировать" энерговыработку: в случае срочной работы - принимаем сахар и воду (чтоб предотвратить обевоживание и растворить сахар), и работаем, если работа длительная - сахар сгорает, и запускается жировой реактор, который тащит еще 12 часов, но сожженные жиры придется компенсировать заранее, иначе сжигать будет нечего, так что если подобные нагрузки не редкость - требуется питание с большим количеством жиров и солей: жидкость вымывает соли из костей, делает их хрупкими, а когда потеем или сжигаем глюкозу с жирами - жидкости из организма, а значит и солей (т.к. раствор), уходит много. Чтоб при всем при этом не сыпались зубы - юзаем пасты с фтором.

    Так что, чтобы лучше себя чувствовать, нужны тренировки, физическая нагрузка, и сжигание жиров - наиболее выгодный и "легкий" источник энергии: запустив реактор, можно окончить тренировку, но продолжить получать энергию еще полсуток! Эти полсуток можно сохранять высокую активность, без истощения, усталости.
    Вот как-то так это все и работает. Наверное поэтому за границей так популярны ежедневные утренние пробежки на свежем воздухе - часик побегал, и целый день как заведенный, но без спец.питания (ограничения сахара) они бесполезны.

    Ссылки любопытствующим: 1, 2, 3, 4, 5, 6

    Исходя из всего вышеизложенного, идеальный рабочий день выглядит так:
    Проснулись, умылись, покушали, часик побегали, искупались, и на работу, первые часы - усваиваем новое, остальные - работаем, после пробежки не кушаем пару часов, весь день не потребляем сахаросодержащее, хаваем рыбку, жиры потребляем исходя из потребностей: нужно поддерживать количество жирка, если начали жиреть - снижаем количество жирной пищи, начали худеть - повышаем. Воду пьем чуть больше нормы, не допускаем перепивания - иначе раздуемся, тут очень хорошо работает спортивная фишка: когда хочется пить, а пить нельзя - полоскают рот водой и сплевывают ее. И каждый день пользуемся фторированной пастой или порошком - не сколько для чистки зубов, сколько от выпадения зубов.
    Ответ написан
    Комментировать
  • Программа для расчета электронный цепей?

    @0x131315
    Симуляторы схем - это spice, проект более 20-ти летней давности. Сейчас все решения так или иначе основаны на нем. Так что гуглить симуляторы надо по слову spice.
    Еще вариант lt spice, для бытового уровня - более чем хватает.
    Ответ написан
    Комментировать
  • Как на самом деле передаются биты по сетевому кабелю?

    @0x131315
    Интернет - это целый мир. Этот мир состоит из миллиардов узлов, соединенных между собой линиями связи - это и есть сеть. Некоторые линии связи тонкие, они соединяют несколько узлов, например несколько компьютеров в здании, или несколько зданий в локальную сеть, некоторые средние - они соединяют одни подсети с другими подсетями, например несколько локальных сетей в пределах города, некоторые - очень толстые, магистрали, они соединяют целые сегменты сети, города, страны, и даже целые материки.
    Для того, чтобы разобраться во всех этих миллиардах связей, чтобы понять, кому и что отправлять, давно, еще за тысячи лет до интернета, придумали такую вещь, как маршрутизация.

    Что такое маршрутизация?
    Маршрутизация - это принцип, определяющий кому передать то или иное сообщение. Он довольно прост: если ты видишь получателя - передай сообщение ему, если не видишь, но знаешь того, кто видит - передай сообщение ему, если не видишь и не знаешь того, кто видит - передай сообщение узлу уровнем выше, дефолтному шлюзу, может быть он сумеет найти получателя.
    Таблица маршрутизации - список узлов, которые ты видишь, а также узлов, известных тебе, которые видят кого-то еще. Также в таблицу маршрутизации входит адрес вышестоящего узла - шлюза по умолчанию, на случай если ты не будешь знать, кому еще передать сообщение.
    Сообщений на узлах скапливается много, поэтому их упаковывают в контейнеры, и отправляют сразу по много штук. В сети такие контейнеры - протоколы, пакеты же - мельчайшие единицы информации, атомы, с которыми эти протоколы работают. В реале - это транспортные контейнеры размером с трейлер, а пакеты - мешки с письмами.
    Узел - любое устройство, подключенное к сети, имеющее заполненную таблицу маршрутизации, т.е. имеющее возможность участвовать в пересылке сообщений. Это не только серверы, аппаратные маршрутизаторы, но и даже твой компьютер.
    Отправители и адресаты же - конкретные приложения, работающие на твоем и других компьютерах, за которыми закреплены определенные номера портов. Именно по номерам портов и идет идентификация отправителей и получателей, номера портов - это адреса отправителей и получателей

    Представь, что тебе надо отправить письмо в другую страну. Письмо - это сообщение.
    Ты пишешь его, опускаешь в почтовый ящик, его забирает почтальон, доставляет на почту. На почту поступают письма от всех жителей района, все они сваливаются в одну большую кучу, и разбираются сортировщиками. Сортировщики - те, кто проверяет письма по таблице маршрутизации.
    Сортировщики, ориентируясь на индекс, разбирают кучу на две части: локальные сообщения и внешние.
    Локальные - предназначенные жителям того же района, почтовое отделение знает, где находятся получатели. Это так называемый localhost. Позже эти сообщения еще раз разбираются по домам: каждый дом обслуживает свой почтальон, он просто берет пачку писем для своих домов и разносит по адресам.
    Внешние - почтовое отделение не знает, где находятся получатели, поэтому отправляется эти сообщения машиной на дефолтный шлюз почтового отделения, городской почтовый узел, где они точно также все складываются в одну кучу, которую точно такие же сортировщики разбирают на те же две кучи: локальные сообщения и внешние.
    Локальные сообщения позже делят на несколько кучек - по одной на каждое почтовое отделение города, их заберут машины этих почтовых отделений, когда доставят новую порцию исходящих писем. Несколько локальных кучек - городской почтовый узел знает тех, кто знает, где находятся получатели - другие городские почтовые отделения.
    Внешние - на две больших группы: сообщения для тех городов, с которыми у этого города налажено регулярное почтовое сообщение - эти сообщения отправляются непосредственно в город, где живет получатель. Все остальные сообщения - их неизвестно куда отправить, поэтому они отправляются на дефолтный шлюз городского почтового отделения - в главпочтамп, в Москву.
    В Москве - центральный сортировочный узел, который имеет связь не только с другими городами и областями, но и с другими странами. Поэтому там письма сортируются на гораздо большее количество кучек, и каждая отправляется в свою сторону.
    Москва также - пограничный шлюз, шлюз между двумя разными сетями, например локальной сетью и городской, или между медью и оптикой, или между городами или материками, в реале - между разными странами.
    На пограничных шлюзах, помимо маршрутизации, осуществляется также конвертация сообщений - преобразование их из одного вида в другой, например из электричества в свет, или меняется адресация подсети, сам формат адресов или же просто смена номера подсети, в реале - проставляется международный штемпель. Также на пограничных шлюзах может идти перепаковка сообщений из одного контейнера в другой, например вместо автомобилей - погрузка на поезд, корабль, или самолет.
    Таким вот образом сообщение попадает на другой пограничный шлюз - центральное почтовое отделение страны назначения, откуда, сверяясь по индексам на конверте, отправляется в городское отделение города назначения, откуда переправляется в отделение с указанным индексом (читай - на компьютер получателя), откуда уже почтальон доставляет его непосредственно получателю - передается в конкретный порт, который слушает приложение, которому предназначено это сообщение.
    Ответ написан
    Комментировать