По поводу опен-сорс - такое себе предложение, особенно для крупных студий. Не учитывается, что одни и те же пропраетарные компоненты используются для создания кучи игр и пускать их в опен сорс - значит тупо забить гвоздь в крышку собственного гроба. А поддерживать убыточный проект до бесконечности - то же самое... Лично у меня по данному вопросу претензий к создателям игра нет, и в особенности их нет к небольшим студиям с небольшим бюджетом. В целом считаю данный вопрос высосанным из пальца. Есть гораздо более актуальные вещи, как то внутриигровые покупки.
В точку. Еще до этого был ассемблер ZX Spectrum. Счастье было, когда раздобыл документацию на нескольких листах. Баловался реверсом Элиты, и код который видел после с точки зрения оптимизаций уже не производит впечатление...
Что-то мне подсказывает, что при упомянутых вводных, обеспечивающих впечатляющий отрицательный рост качества образования наших отпрысков, вопрос выбора языка глубоко вторичен. Сильно сочувствую автору, всем занятым в российском образовании и всем нашим детям. Сам в школе в 90-е учил всякие Бейсики, на школьном факультативе - Пролог, на УПК - Фортран, а дома - ассемблер. Времена меняются...
IMHO в сценарии ОС после окончания поддержки основная проблема - новые дыры в безопасности, которые уже никто не будет как латать, так и закачивать вам автоматом фиксы. Лично для меня это no-go.
Если что по каждому домену надо в portfolio поменять контактную информацию, меняется с задержкой 24 часа. Поддержка тупит, проверили и выслали ссылку на изменение контактов только по одному домену и потом сказали все в порядке. Догадался спросить надо ли менять остальные... А то удалят и доказывай что не верблюд.
Т.о. проверяйте в трех местах: (1) контакты по каждому домену в portfolio (2) контактная информация в Account Settings и (3) адрес биллинга в Renewals & Billing
И другая сторона медали: люди с клиповым мышлением делают быстро, но все делают по минимуму, на минимально достаточном уровне. Может в каких-то вещах это нормально, но очень часто такой подход создает проблемы на будущее. Например, когда клиенты видят, что сделано чуть больше или чуть качественнее, чем они ожидали - они имеют тенденцию возвращаться. У "клиповиков" результат работы будет чаще всего "удовл", а не "хор" и "отл".
Terence McKenna 's Final Interview. Только о теории новизны и говорит) 1998. Без комментариев на предмет верности этого всего, но ребята прям открыли Америку...
Вопрос в том, что в такой сложности моделях разработчики уже сами не всегда знают, какой же там алгоритм и как сеть отреагирует на тот или иной запрос... Именно это и позволяет многим говорить о чертах ИИ.
Про ассемблер всегда интересно, но вот писать на нем прогу с графическим интерфейсом для виндов - это за рамками его практического применения совсем. Какой-нить более прагматичный кейс был бы уместен... Плюсую все равно)
Не понимаю почему из "какой-нибудь Черногории" предложенный вариант выглядит существенно лучше. Все примерно то же самое, и деревня, и медицина, и товары из других стран... По административным барьерам: судя по тексту не сильно легче обосноваться, чем в остальной Европе.
Без обид, но лучше на Вы, лично не знакомы. Вообще это ни разу не про ассемблер, а про базовые принципы представления программы в памяти. То есть лично для меня это из области "что такое 32-битная или 64-битная ОС". Если пишете на языке достаточно низкого уровня (как С), то предполагается, что базовый курс по компьютерной архитектуре за плечами имеется. Материала в сети сейчас на эту тему масса, хотя для полного понимания я бы посоветовал действительно "закопаться" в ассемблер, в любом учебнике по ассемблеру разжеваны основы архитектуры, в том числе адресация. Я лично не совсем представляю себе программиста на С без знания основ ассемблера. Удачи в свершениях, ждем профессиональных статей на Хабре.
Итак, дорогие читатели-потенциальные Си программисты, вы должны были понять, что размер указателя одинаковый в пределах программы на одном компьютере.
Я бы читателям лучше по С любую книжку прочитать бы посоветовал, в которой будет написано, что указатели хранят АДРЕС переменной в памяти, и тогда вопросов про размер указателя, равенство размеров указателей и т.п. не возникло бы) PS. Сам на C не пишу, но стало интересно.
А мне кажется конкретно на данный момент не так важно робот там, граната или пуля. У Азимова у робота был искусственный интеллект, сейчас же это просто ведро с гайками которое громко называется роботом. Использование механических устройств в крайних случаях в теории может спасти жизни полицейским, это аргумент. Нас, конечно, от этого несколько коробит, так как на будущее закладывает нехорошие перспективы использования робота с более развитым программным обеспечением (читай искусственным интеллектом), и чем больше кода, тем больше в нем ошибок...
Дык кто-ж спорит... Прямо сейчас закончил SPA Quasar+Laravel, полностью доволен своим выбором... Но за своим серваком надо следить, это доп затраты и риски. Когда стартовал изучал возможность полного serverless, но по производительности и костам меня не устроило, хотя все развивается, и мб по другому проекту выбор уже будет другой. На полном serverless стэке я бы скорее рассматривал Node или Python...
Про работающие проекты вопросов как раз нет. Вопрос в том, какой стэк выбрать тем, кто начинает новые на serverless архитектуре. При прочих равных сейчас я бы php не выбрал для этих целей.
Да, я в курсе, спасибо. IMHO эти варианты вымрут со временем, т.к. конкретно для serverless стэка есть более оптимальные решения, и новые проекты будут базироваться именно на них.
С точки зрения программиста как наемного работника к php и Laravel, конечно, могут быть претензии. Но с точки зрения старта новых проектов Laravel - это один из лучших, мощных и высокоструктурированных инструментов для обработки запросов на стороне сервера => высокая скорость разработки и низкие затраты, плюс специалисты на рынке присутствуют. Если в приоритете вопросы не моды, а эффективности, то для этих целей оптимальный вариант (ну или один из).На мой взгляд, основная проблема php не в текущем моменте, а в перспективе, так как в спину дышит serverless, и ключевое поле деятельности для php будет плавно сокращаться...
Собственно, требование высшего образования на позицию офис-менеджера лишь констатирует избыток людей с высшим образованием в РФ. Если можно получить офис-менеджера с высшим - конечно, лучше с высшим, вопроса-то и споров тут особо не просматривается)
По поводу опен-сорс - такое себе предложение, особенно для крупных студий. Не учитывается, что одни и те же пропраетарные компоненты используются для создания кучи игр и пускать их в опен сорс - значит тупо забить гвоздь в крышку собственного гроба. А поддерживать убыточный проект до бесконечности - то же самое... Лично у меня по данному вопросу претензий к создателям игра нет, и в особенности их нет к небольшим студиям с небольшим бюджетом. В целом считаю данный вопрос высосанным из пальца. Есть гораздо более актуальные вещи, как то внутриигровые покупки.
В точку. Еще до этого был ассемблер ZX Spectrum. Счастье было, когда раздобыл документацию на нескольких листах. Баловался реверсом Элиты, и код который видел после с точки зрения оптимизаций уже не производит впечатление...
Что-то мне подсказывает, что при упомянутых вводных, обеспечивающих впечатляющий отрицательный рост качества образования наших отпрысков, вопрос выбора языка глубоко вторичен. Сильно сочувствую автору, всем занятым в российском образовании и всем нашим детям. Сам в школе в 90-е учил всякие Бейсики, на школьном факультативе - Пролог, на УПК - Фортран, а дома - ассемблер. Времена меняются...
IMHO в сценарии ОС после окончания поддержки основная проблема - новые дыры в безопасности, которые уже никто не будет как латать, так и закачивать вам автоматом фиксы. Лично для меня это no-go.
Если что по каждому домену надо в portfolio поменять контактную информацию, меняется с задержкой 24 часа. Поддержка тупит, проверили и выслали ссылку на изменение контактов только по одному домену и потом сказали все в порядке. Догадался спросить надо ли менять остальные... А то удалят и доказывай что не верблюд.
Т.о. проверяйте в трех местах: (1) контакты по каждому домену в portfolio (2) контактная информация в Account Settings и (3) адрес биллинга в Renewals & Billing
И другая сторона медали: люди с клиповым мышлением делают быстро, но все делают по минимуму, на минимально достаточном уровне. Может в каких-то вещах это нормально, но очень часто такой подход создает проблемы на будущее. Например, когда клиенты видят, что сделано чуть больше или чуть качественнее, чем они ожидали - они имеют тенденцию возвращаться. У "клиповиков" результат работы будет чаще всего "удовл", а не "хор" и "отл".
Terence McKenna 's Final Interview. Только о теории новизны и говорит) 1998. Без комментариев на предмет верности этого всего, но ребята прям открыли Америку...
Вопрос в том, что в такой сложности моделях разработчики уже сами не всегда знают, какой же там алгоритм и как сеть отреагирует на тот или иной запрос... Именно это и позволяет многим говорить о чертах ИИ.
Про ассемблер всегда интересно, но вот писать на нем прогу с графическим интерфейсом для виндов - это за рамками его практического применения совсем. Какой-нить более прагматичный кейс был бы уместен... Плюсую все равно)
Не понимаю почему из "какой-нибудь Черногории" предложенный вариант выглядит существенно лучше. Все примерно то же самое, и деревня, и медицина, и товары из других стран... По административным барьерам: судя по тексту не сильно легче обосноваться, чем в остальной Европе.
Видимо, стоит обмолвиться, что речь идет о Windows)
Без обид, но лучше на Вы, лично не знакомы. Вообще это ни разу не про ассемблер, а про базовые принципы представления программы в памяти. То есть лично для меня это из области "что такое 32-битная или 64-битная ОС". Если пишете на языке достаточно низкого уровня (как С), то предполагается, что базовый курс по компьютерной архитектуре за плечами имеется. Материала в сети сейчас на эту тему масса, хотя для полного понимания я бы посоветовал действительно "закопаться" в ассемблер, в любом учебнике по ассемблеру разжеваны основы архитектуры, в том числе адресация. Я лично не совсем представляю себе программиста на С без знания основ ассемблера. Удачи в свершениях, ждем профессиональных статей на Хабре.
Я бы читателям лучше по С любую книжку прочитать бы посоветовал, в которой будет написано, что указатели хранят АДРЕС переменной в памяти, и тогда вопросов про размер указателя, равенство размеров указателей и т.п. не возникло бы) PS. Сам на C не пишу, но стало интересно.
А мне кажется конкретно на данный момент не так важно робот там, граната или пуля. У Азимова у робота был искусственный интеллект, сейчас же это просто ведро с гайками которое громко называется роботом. Использование механических устройств в крайних случаях в теории может спасти жизни полицейским, это аргумент. Нас, конечно, от этого несколько коробит, так как на будущее закладывает нехорошие перспективы использования робота с более развитым программным обеспечением (читай искусственным интеллектом), и чем больше кода, тем больше в нем ошибок...
Вот и я о том же, ПОКА это так. Но ситуация быстро меняется.
Дык кто-ж спорит... Прямо сейчас закончил SPA Quasar+Laravel, полностью доволен своим выбором... Но за своим серваком надо следить, это доп затраты и риски. Когда стартовал изучал возможность полного serverless, но по производительности и костам меня не устроило, хотя все развивается, и мб по другому проекту выбор уже будет другой. На полном serverless стэке я бы скорее рассматривал Node или Python...
Про работающие проекты вопросов как раз нет. Вопрос в том, какой стэк выбрать тем, кто начинает новые на serverless архитектуре. При прочих равных сейчас я бы php не выбрал для этих целей.
Да, я в курсе, спасибо. IMHO эти варианты вымрут со временем, т.к. конкретно для serverless стэка есть более оптимальные решения, и новые проекты будут базироваться именно на них.
С точки зрения программиста как наемного работника к php и Laravel, конечно, могут быть претензии. Но с точки зрения старта новых проектов Laravel - это один из лучших, мощных и высокоструктурированных инструментов для обработки запросов на стороне сервера => высокая скорость разработки и низкие затраты, плюс специалисты на рынке присутствуют. Если в приоритете вопросы не моды, а эффективности, то для этих целей оптимальный вариант (ну или один из).На мой взгляд, основная проблема php не в текущем моменте, а в перспективе, так как в спину дышит serverless, и ключевое поле деятельности для php будет плавно сокращаться...
Собственно, требование высшего образования на позицию офис-менеджера лишь констатирует избыток людей с высшим образованием в РФ. Если можно получить офис-менеджера с высшим - конечно, лучше с высшим, вопроса-то и споров тут особо не просматривается)