Само описание файлов и их приблизительное местоположение. Ты не будешь искать то, о существовании чего не подозреваешь. И, соответственно, появляется худо-бедное понимание происходящего.
В противном случае, например, древнюю книжку K&R можно просто выкинуть в ведро, потому что "все давно пишут ОС на JS" : )
Газы вызывают основную часть запаха, но это ни разу не отменяет воздушно-капельную взвесь в воздухе, содержащую практически все говёные компоненты с поверхности говна, которая есть везде где есть и запах говна, и даже там где нет запаха - она тоже зачастую есть : ) Ну и газы разве не являются частицами говна? Вполне они самые.
В качестве вводной статьи-экскурсии, тем не менее, более чем сойдёт, для изучающих тему. Тем более что полагаю, у статьи нет цели описать "все-все существующие модные или современные конфигурируемые сервисы-демоны". Изучающему человеку это понадобится позже и он сам разберётся, пользуясь базой из статьи. Так что монопенисуально.
Проблема в том, что вы выходите на улицу и дышите уличным воздухом. Заходите в метро, и дышите кучей чужих микробов. Заходите в офис, где большая часть людей за пару лет уже хорошенько обменялись всеми своими микробами.
И туалетный шлейф занимает настолько мизерную долю в этом деле, и настолько незначителен, что обращать на него внимание - имеет явные признаки пугалок "ууууу совмещённый санузел это всё равно что какашки размазанные по вашим зубным щёткам". Это конечно недалеко от истины, но простите, на что человеку иммунитет? Мы ежедневно вдыхаем пару грамм чужого говна, пота и слюней, просто во время уличного времяпровождения, но почему-то к зубной щётке и своему унитазу особое отношение.
Напоминаю: если вы чуете запах говна, это самые настоящие частицы говна у вас в носу. Но если у вас нет ОКР, повёрнутости на стерильности, психических отклонений или особых заболеваний вроде иммунодефицита, то вам на это примерно побарабану. Пока вы не услышите новую пугалку.
Если для вас "если не хайлоад - то это не работа а на поиграться", то конечно да. Правда, звучит это довольно по-дилетантски - хайлоад это просто немножко другой класс задач, особой сложностью, с учётом имеющегося инструментария, не обладающий.
Ну смотрите. У нас есть языки программирования с крайне упрощённым английским, для изучения которого не нужно применять никаких особенных усилий.
В противном случае, давайте в каждой стране делать свою локализацию каждого языка. Теперь, в вашей огромной организации, половина кодовой базы на английском, четверть на русском (с другой терминологией, пришедшей в голову разработчиком, и ещё четверть на бурятском. А какие-то особо важные ключевые моменты на хинди и иддише, потому что почему бы и нет. А самое приятное, что изначально всё это допустим питон. Просто разработчики решили что будут делать как им "удобнее" и роднее :)
В общем, это буквально расслоение абстракций на разные языки, что будет приводить к очень интересным моментам с отладкой.
Это достаточно редкий случай организации. Подобное тоже встречается, но туда ещё надо попасть блин, и быть достаточно неопытным чтобы не просечь это на старте. Если с самого начала бросают в лигаси и вынуждают решать неизвестные проблемы и не дают ни у кого спрашивать - тут повод или с кем-то скорешиться, кто поможет первое время с общими элементами системы, а если таких нет то.. Можно просто уволиться и найти место где дадут нормальное время на освоение?
Очень просто. Я бы сказал что чересчур :) Во-первых, используемый вами протокол TCP безусловно хорош, но сервер который принимает только одно соединение, извлекает из него всё что в него отправили и тут же закрывается это немножко малоюзабельно. Что-то на уровне > Как в языке Python сделать Hello World? Всего лишь print("Hello World")! Ничего другого не надо! То есть это прямо скажем не сервер, а "Как прослушать порт, и принять из него что-нибудь", притом его легко полностью парализовать не завершая соединение :)
Первое что имеет любой сервер: - Некоторый менеджер соединений. В него мы добавляем клиентов. - Некоторые абстракции над sock'ами, условные клиенты, которыми мы такие, желательно в неблокирующем виде, принимаем все присланные данные всеми sock'ами (сколько прислали столько неблокирующе и считываем, и если сообщение не закончено то переходим к следующему), отключаем клиентов по таймаутам, проверяем что они нам что-то прислали и выполняем на присланные сообщения какие-нибудь callback'и. - Некоторый абстрактный формат сообщений. Протокол TCP ориентирован не на сообщения, а на потоки, и ему нужен дополнительный формат для разделения сообщений, вы же не хотите использовать одно целое соединение чтобы прислать одно сообщение, когда их может быть пачка? Простейший формат сообщений -- message + "\r\n", и эти "\r\n" работают разделителями сообщений. Но у него проблема с самими данными, их приходится паковать в какой-нибудь base64 чтобы из-за тела сообщения содержащего эти самые "\r\n" мессага не распилилась, поэтому чуть более сложный вариант, например text = "abcdef" formatted = '{0:04d}{1:s}'.format(len(text), text) > '0006abcdef' Приведёт к уникальной возможности указывать длину сообщения перед самим сообщением, и корректно их сепарировать по длине, принимая и отправляя их сразу пачками (хотя появляется лимит на длину, которую можно указать произвольной, но она внесёт некоторый оверхед). Я сам использую похожие прикладные протоколы для своих небольших нужд, где HTTP слишком тяжеловесен, и что-то похожее используется в самом HTTP, только там чуть более комплексный заголовок, содержащий не только длину а сразу множество опций, и само тело там может быть а может не быть, но это уже частности.
И вот чего-то подобного хотелось бы видеть в статье а не только "Мы открыли сокет! Мы отправили в него строчку и приняли! Ура!". Статья неплоха как вводная часть, перед дальнейшей кухней вроде той что я описал, но ПОСЛЕ теоретической части которой тоже не хватает: что такое сервер? что такое сокет? что такое порт? что такое tcp/udp/ip? Почему localhost и что он означает, во что трансформируется и почему? Ваше описание избыточно упрощено, и мало имеет отношения к действительности :)
Ну и в третьих, хаб "Серверное администрирование" немножко кажется тоже лишним, здесь примерно ничего про администрирование, про роутинг, пробитие или использование портов, фаерволы и так далее :)
Хммм. На случай если это всё таки не разговоры с копипастой. Первый месяц при устройстве на новую работу программистом обычно приблизительно выясняешь стек и внутреннюю кухню. Написать за месяц ни строчки это конечно жирновато, но в целом, нормально при знакомстве с проектом - берём проект и начинаем раскапывать. Абстрагировать на куски по предметной области, где что почему. И расписывать на бумажке дерево диаграмм зависимостей: "Та-а-ак, эти ветки файлов глобально отвечают за вот это, их писали вот эти и эти люди, использовали такие и такие технологии", и таким образом зохавывается весь проект, попутно поглядывая документацию и спрашивая кто где что и зачем сделал.
Когда я устраивался на свою первую работу программистом, возникало острое желание всё нафиг переписать потому что "это слишком топорно и неизящно, это слишком сложно, тут копипаста дикая и вообще её как будто бухим писали". Сами архитектурные модули внутренней кухни были в целом неплохо абстрагированы, ибо ими занималось небольшое количество человек (всего штук пять-семь за всё время), но их внутреннее описание кошмарно. А потом я понял почему именно оно так написано, и внезапно осознал что сам пишу примерно то же самое, и что это нормально и что жизнь слишком коротка чтобы всё вылизывать. Но новичков немного жалко.
Этап самозванца нужно пережить, и спрашивать людей стараясь вникнуть, иначе все вокруг так и будут казаться умными умниками, хотя у них просто опыт копания в говне есть. Пока сам не перероешь миллион строчек говнокода и не напишешь свой - ничего не будет. А пара-тройка месяцев "вхолостую" это обычная практика при обучении, потом компенсируешь качеством работы.
Разумеется нет. Но все достаточно популярные сайты с высокой посещаемостью делают те или иные варианты повышения инклюзивности хотя бы через контраст, и в целом, перевод страницы в ЧБ и устранение недостаточно контрастных мест всегда было хорошим тоном не только при проектировании интерфейсов, но и в любых концепт-артах, левел-дизайне например, и в целом, достаточная контрастность резко улучшает восприятие не только при наличии отклонений цветового восприятия.
Ух, сколько комментариев.
От себя могу предложить прекратить интеллектуально наяривать, и просто смириться с собственной тупизной и ограниченностью собственного восприятия, научного подхода и всего остального. В противном случае, почему ни один из умных умников комментаторов не занимает лидирующие позиции в списке форбс и какого-нибудь (разумеется, организованного ими же) тайного мирового правительства?
Всё что можно сказать о мире и вселенной — «в нём происходят разные штуки, и люди иногда наблюдают в них некоторые закономерности», всё остальное — суть проявление крюгеризма. И этот коммент тоже.
С одной стороны, проблемы с многопоточностью/тредингом решаются опять таки теми самыми библиотеками с Github (luarocks, аналог pip) и всякими корутинами, а фатальные ошибки с перехватом управления — pcall/xpcall'ами, но таки да, Lua имеет бОльшие требования к рукам программописателей чем Python, хотя бы потому что всё происходит в ручном режиме, практически без библиотечных функций. Ну и Lua требует более плотной работы с экосистемой: нема волшебого pip'а, который загрузит бинарь под все возможные архитектуры, иногда что-то приходится компилировать самостоятельно.
А вот вопрос, чему лучше учить всё ещё открыт: с одной стороны, Lua, как Basic и Pascal в стародавние времена (позже на них начали делать в т.ч. продакшн) — заставляет переходить на что-то более высокооплачиваемое, и этим выводит из положения «мой первый яп — моя главная религия по жизни», принуждая к мысли что «язык это инструмент», что является весьма полезным, особенно для новичков, а после Python'а, начинающие питонисты сразу пытаются идти работать, не изучив ни паттерны-шаблоны, ни собственно программирование, ни внутреннюю организацию самого Python'а.
Моё скромное мнение в том, что на Lua можно дать весьма широкий уровень образования, начиная с основ и различных реализаций ООП в разных ЯП, и заканчивая полноценным Computer Science (библиотек-то немного, приходится разбираться самостоятельно, хотя есть torch), но это не уместишь в сравнительно простой и короткий курс, для этого в идеале нужна пара лет, зато на выходе — отличный специалист, не привязанный ни к языку ни к платформе :)
Не совсем.
Конструктивно, электронная сигарета состоит из трёх частей:
1. Аккумулятор (батарейный блок)
2. Испаритель (спиралька) + некоторый объём для жидкости (бачок/пропитанная жидкостью вата)
3. Корпус и требуха (микрофон/кнопка активации, платы заряда/защиты/регулировки)
И слабое звено, в случае заряжаемого аккумулятора — испаритель, он загрязняется ароматизаторами и перестаёт функционировать должным образом, даёт привкус гари и хуже испаряет. При плохой герметичности, после перезаправки, жидкость начинает перетекать в карман. Первое можно обойти, если заправлять одноразовую ЭС жидкостями без ароматизаторов: хорошо очищенный глицерин и опц. никотин полностью испаряются, практически не загрязняя испаритель, второе — зависит от конструктива.
Но это — изготовление автобуса из буханки хлеба: для комфортного многократного использования одноразки, требуется встраивание платы заряда, чтобы не допускать перезаряда аккумулятора (или разработать специальную зарядку), разработать механизм заправки без переливов и ещё много всего.
И выглядеть это будет весьма колхозно. Эффективнее разбирать и пускать аккумуляторы на запчасти.
«Высокоуровневый проприетарный проект» означает «кучу правок разных людей во время дедлайнов», там совершенно нормально писать хромоногие химеры. Потом отрефакторят. Или нет.
Игровой фреймворк love2d использует технологию аналогичную rarjpeg: в конец исполняемого файла просто подшивается архив с ресурсами игры, и при исполнении, открывает сам себя как архив, выуживая оттуда main-скрипт как точку входа, попутно монтируя себя в качестве корневого каталога местной виртуальной ФС.
Читалкам архивов всё равно, что в начале исполняемого файла есть какие-то байты, он ищет заголовок архива и начинает работать с ним.
В языках с худо-бедно строгой типизацией, будут ошибки вроде «невозможно сложить число с массивом», когда извне приходит не то что ожидалось, и из-за этого может вылезать гора ошибок. И вот из-за этого некоторые ребята называют жаваскрипт дурацким, потому что при беглом прогоне как бы должна была выскочить ошибка, а её не было, всё как бы нормально, потом ошибка идёт дальше неотловленной.
Это только одно из мнений, их множество.
Внезапный veritasum по поводу.
Само описание файлов и их приблизительное местоположение.
Ты не будешь искать то, о существовании чего не подозреваешь.
И, соответственно, появляется худо-бедное понимание происходящего.
В противном случае, например, древнюю книжку K&R можно просто выкинуть в ведро, потому что "все давно пишут ОС на JS" : )
Газы вызывают основную часть запаха, но это ни разу не отменяет воздушно-капельную взвесь в воздухе, содержащую практически все говёные компоненты с поверхности говна, которая есть везде где есть и запах говна, и даже там где нет запаха - она тоже зачастую есть : )
Ну и газы разве не являются частицами говна? Вполне они самые.
В качестве вводной статьи-экскурсии, тем не менее, более чем сойдёт, для изучающих тему.
Тем более что полагаю, у статьи нет цели описать "все-все существующие модные или современные конфигурируемые сервисы-демоны". Изучающему человеку это понадобится позже и он сам разберётся, пользуясь базой из статьи. Так что монопенисуально.
Проблема в том, что вы выходите на улицу и дышите уличным воздухом.
Заходите в метро, и дышите кучей чужих микробов.
Заходите в офис, где большая часть людей за пару лет уже хорошенько обменялись всеми своими микробами.
И туалетный шлейф занимает настолько мизерную долю в этом деле, и настолько незначителен, что обращать на него внимание - имеет явные признаки пугалок "ууууу совмещённый санузел это всё равно что какашки размазанные по вашим зубным щёткам". Это конечно недалеко от истины, но простите, на что человеку иммунитет? Мы ежедневно вдыхаем пару грамм чужого говна, пота и слюней, просто во время уличного времяпровождения, но почему-то к зубной щётке и своему унитазу особое отношение.
Напоминаю: если вы чуете запах говна, это самые настоящие частицы говна у вас в носу. Но если у вас нет ОКР, повёрнутости на стерильности, психических отклонений или особых заболеваний вроде иммунодефицита, то вам на это примерно побарабану. Пока вы не услышите новую пугалку.
На Gamasutra есть отличная статья от разработчика Mushroom 11, по камерам в двухмерных играх с миллиардами примеров для разных целей:
https://www.gamedeveloper.com/design/scroll-back-the-theory-and-practice-of-cameras-in-side-scrollers
Если для вас "если не хайлоад - то это не работа а на поиграться", то конечно да. Правда, звучит это довольно по-дилетантски - хайлоад это просто немножко другой класс задач, особой сложностью, с учётом имеющегося инструментария, не обладающий.
Ну смотрите. У нас есть языки программирования с крайне упрощённым английским, для изучения которого не нужно применять никаких особенных усилий.
В противном случае, давайте в каждой стране делать свою локализацию каждого языка.
Теперь, в вашей огромной организации, половина кодовой базы на английском, четверть на русском (с другой терминологией, пришедшей в голову разработчиком, и ещё четверть на бурятском. А какие-то особо важные ключевые моменты на хинди и иддише, потому что почему бы и нет.
А самое приятное, что изначально всё это допустим питон. Просто разработчики решили что будут делать как им "удобнее" и роднее :)
В общем, это буквально расслоение абстракций на разные языки, что будет приводить к очень интересным моментам с отладкой.
Это достаточно редкий случай организации. Подобное тоже встречается, но туда ещё надо попасть блин, и быть достаточно неопытным чтобы не просечь это на старте.
Если с самого начала бросают в лигаси и вынуждают решать неизвестные проблемы и не дают ни у кого спрашивать - тут повод или с кем-то скорешиться, кто поможет первое время с общими элементами системы, а если таких нет то.. Можно просто уволиться и найти место где дадут нормальное время на освоение?
Ответ хороший, но суть в том, что по хорошему он должен быть в теле статьи :)
Очень просто. Я бы сказал что чересчур :)
Во-первых, используемый вами протокол TCP безусловно хорош, но сервер который принимает только одно соединение, извлекает из него всё что в него отправили и тут же закрывается это немножко малоюзабельно. Что-то на уровне
> Как в языке Python сделать Hello World? Всего лишь print("Hello World")! Ничего другого не надо!
То есть это прямо скажем не сервер, а "Как прослушать порт, и принять из него что-нибудь", притом его легко полностью парализовать не завершая соединение :)
Первое что имеет любой сервер:
- Некоторый менеджер соединений. В него мы добавляем клиентов.
- Некоторые абстракции над sock'ами, условные клиенты, которыми мы такие, желательно в неблокирующем виде, принимаем все присланные данные всеми sock'ами (сколько прислали столько неблокирующе и считываем, и если сообщение не закончено то переходим к следующему), отключаем клиентов по таймаутам, проверяем что они нам что-то прислали и выполняем на присланные сообщения какие-нибудь callback'и.
- Некоторый абстрактный формат сообщений. Протокол TCP ориентирован не на сообщения, а на потоки, и ему нужен дополнительный формат для разделения сообщений, вы же не хотите использовать одно целое соединение чтобы прислать одно сообщение, когда их может быть пачка? Простейший формат сообщений -- message + "\r\n", и эти "\r\n" работают разделителями сообщений. Но у него проблема с самими данными, их приходится паковать в какой-нибудь base64 чтобы из-за тела сообщения содержащего эти самые "\r\n" мессага не распилилась, поэтому чуть более сложный вариант, например
text = "abcdef"
formatted = '{0:04d}{1:s}'.format(len(text), text)
> '0006abcdef'
Приведёт к уникальной возможности указывать длину сообщения перед самим сообщением, и корректно их сепарировать по длине, принимая и отправляя их сразу пачками (хотя появляется лимит на длину, которую можно указать произвольной, но она внесёт некоторый оверхед). Я сам использую похожие прикладные протоколы для своих небольших нужд, где HTTP слишком тяжеловесен, и что-то похожее используется в самом HTTP, только там чуть более комплексный заголовок, содержащий не только длину а сразу множество опций, и само тело там может быть а может не быть, но это уже частности.
И вот чего-то подобного хотелось бы видеть в статье а не только "Мы открыли сокет! Мы отправили в него строчку и приняли! Ура!". Статья неплоха как вводная часть, перед дальнейшей кухней вроде той что я описал, но ПОСЛЕ теоретической части которой тоже не хватает: что такое сервер? что такое сокет? что такое порт? что такое tcp/udp/ip? Почему localhost и что он означает, во что трансформируется и почему? Ваше описание избыточно упрощено, и мало имеет отношения к действительности :)
Ну и в третьих, хаб "Серверное администрирование" немножко кажется тоже лишним, здесь примерно ничего про администрирование, про роутинг, пробитие или использование портов, фаерволы и так далее :)
Хммм. На случай если это всё таки не разговоры с копипастой. Первый месяц при устройстве на новую работу программистом обычно приблизительно выясняешь стек и внутреннюю кухню. Написать за месяц ни строчки это конечно жирновато, но в целом, нормально при знакомстве с проектом - берём проект и начинаем раскапывать. Абстрагировать на куски по предметной области, где что почему. И расписывать на бумажке дерево диаграмм зависимостей: "Та-а-ак, эти ветки файлов глобально отвечают за вот это, их писали вот эти и эти люди, использовали такие и такие технологии", и таким образом зохавывается весь проект, попутно поглядывая документацию и спрашивая кто где что и зачем сделал.
Когда я устраивался на свою первую работу программистом, возникало острое желание всё нафиг переписать потому что "это слишком топорно и неизящно, это слишком сложно, тут копипаста дикая и вообще её как будто бухим писали". Сами архитектурные модули внутренней кухни были в целом неплохо абстрагированы, ибо ими занималось небольшое количество человек (всего штук пять-семь за всё время), но их внутреннее описание кошмарно. А потом я понял почему именно оно так написано, и внезапно осознал что сам пишу примерно то же самое, и что это нормально и что жизнь слишком коротка чтобы всё вылизывать. Но новичков немного жалко.
Этап самозванца нужно пережить, и спрашивать людей стараясь вникнуть, иначе все вокруг так и будут казаться умными умниками, хотя у них просто опыт копания в говне есть. Пока сам не перероешь миллион строчек говнокода и не напишешь свой - ничего не будет. А пара-тройка месяцев "вхолостую" это обычная практика при обучении, потом компенсируешь качеством работы.
Разумеется нет. Но все достаточно популярные сайты с высокой посещаемостью делают те или иные варианты повышения инклюзивности хотя бы через контраст, и в целом, перевод страницы в ЧБ и устранение недостаточно контрастных мест всегда было хорошим тоном не только при проектировании интерфейсов, но и в любых концепт-артах, левел-дизайне например, и в целом, достаточная контрастность резко улучшает восприятие не только при наличии отклонений цветового восприятия.
От себя могу предложить прекратить интеллектуально наяривать, и просто смириться с собственной тупизной и ограниченностью собственного восприятия, научного подхода и всего остального. В противном случае, почему ни один из умных умников комментаторов не занимает лидирующие позиции в списке форбс и какого-нибудь (разумеется, организованного ими же) тайного мирового правительства?
Всё что можно сказать о мире и вселенной — «в нём происходят разные штуки, и люди иногда наблюдают в них некоторые закономерности», всё остальное — суть проявление крюгеризма. И этот коммент тоже.
А вот вопрос, чему лучше учить всё ещё открыт: с одной стороны, Lua, как Basic и Pascal в стародавние времена (позже на них начали делать в т.ч. продакшн) — заставляет переходить на что-то более высокооплачиваемое, и этим выводит из положения «мой первый яп — моя главная религия по жизни», принуждая к мысли что «язык это инструмент», что является весьма полезным, особенно для новичков, а после Python'а, начинающие питонисты сразу пытаются идти работать, не изучив ни паттерны-шаблоны, ни собственно программирование, ни внутреннюю организацию самого Python'а.
Моё скромное мнение в том, что на Lua можно дать весьма широкий уровень образования, начиная с основ и различных реализаций ООП в разных ЯП, и заканчивая полноценным Computer Science (библиотек-то немного, приходится разбираться самостоятельно, хотя есть torch), но это не уместишь в сравнительно простой и короткий курс, для этого в идеале нужна пара лет, зато на выходе — отличный специалист, не привязанный ни к языку ни к платформе :)
Конструктивно, электронная сигарета состоит из трёх частей:
1. Аккумулятор (батарейный блок)
2. Испаритель (спиралька) + некоторый объём для жидкости (бачок/пропитанная жидкостью вата)
3. Корпус и требуха (микрофон/кнопка активации, платы заряда/защиты/регулировки)
И слабое звено, в случае заряжаемого аккумулятора — испаритель, он загрязняется ароматизаторами и перестаёт функционировать должным образом, даёт привкус гари и хуже испаряет. При плохой герметичности, после перезаправки, жидкость начинает перетекать в карман. Первое можно обойти, если заправлять одноразовую ЭС жидкостями без ароматизаторов: хорошо очищенный глицерин и опц. никотин полностью испаряются, практически не загрязняя испаритель, второе — зависит от конструктива.
Но это — изготовление автобуса из буханки хлеба: для комфортного многократного использования одноразки, требуется встраивание платы заряда, чтобы не допускать перезаряда аккумулятора (или разработать специальную зарядку), разработать механизм заправки без переливов и ещё много всего.
И выглядеть это будет весьма колхозно. Эффективнее разбирать и пускать аккумуляторы на запчасти.
Читалкам архивов всё равно, что в начале исполняемого файла есть какие-то байты, он ищет заголовок архива и начинает работать с ним.
Это только одно из мнений, их множество.