Обычная либа подключается за час, сильно хитрая — за день.
С порядком ваших оценок совершенно согласен, но обычно либа — не одна, отсюда и неделя вместо одного дня. А даже если вдруг одна, она обычно тянет за собой ещё парочку, а их сборка — опять же на ваших плечах.
Те, кто считает, что самая большая проблема C++ это его «небезопасная» природа… очень сильно заблуждаются. Самая большая проблема С++ заключается в том, что код на этом языке тяжело писать, читать, отлаживать, профилировать и поддерживать.
Самая большая проблема C++ — это отсутствие менеджера пакетов. В Go/Rust/Python/Ruby/JavaScript/Java/.NET вы находите подходящие инструменты и решаете задачу (ну может с Go и Rust я немного погорячился). В C++ вы находите подходящие инструменты, неделю их подключаете, ещё неделю пишете README по настройке dev энвайронмента, и только после этого решаете задачу.
Желание закончить игру не на пенсии, в маразме, а пока молодой
Это не проблема отсутствия времени: чаще всего проблема в самодисциплине и расстановке приоритетов. Без в/о и постоянной работы точно так же можно дотянуть до пенсии (при условии, что есть где жить и что есть).
желание заниматься тем, что нравится (не как хобби, а по жизни)
Стоило рассмотреть вариант устройства на работу в геймдев контору. Ваша полуготовая игра очень хорошо помогла бы на собеседовании. Это позволило бы и постоянный источник дохода иметь и, что более важно, возможность общаться с более опытными коллегами. Не говоря уже о том, чтобы посмотреть «как это делают другие».
неприятие устоявшейся отечественной системы образования
Наличие в/о действительно очень редко как-то связано с толковостью специалиста, но есть интересные нюансы: например, без образования практически невозможно «уехать».
желание и возможность уже сейчас зарабатывать деньги
Вы пока не сделали ничего для того, чтобы заработать деньги. Улучшение кода, графики и геймплея не приближает вас к зарабатыванию денег, как бы ни хотелось в это верить. Вот если сейчас бросите заниматься перфекционизмом и попробуете на игре заработать хотя бы 1 доллар — это будет огромный шаг в правильную сторону.
Я тогда наверное не понял о чём статья.
1. Статья называется «Сажаем контроллеры на диету». Т.е. про контроллеры.
2. В начале статьи сказано: «При использовании MVC в Android, Activity или Fragment является контроллером». Т.е. я в первую очередь смотрю на код Activity, потому что сказано, что «статья про контроллеры, а контроллеры — это Activity».
Посмотрел — прокомментировал. Интересно было бы посмотреть, насколько чистый код получился бы, если бы вы канонично связь model->view делали через Loader, а controller->model через IntentService. У меня есть искренние сомнения по поводу того, что от предложенного подхода в итоге что-то останется.
Предложенный подход не будет работать на практике: подписка Activity на AsyncTask — это наверное самая популярная джуниорская ошибка. Приводит к падениям (или зависаниям, или вообще не понятно к чему — как повезёт) при попытках перевернуть девайс в процессе выполнения сравнительно долгих операций. А чтобы от этой ошибки избавиться, нужно изобразить что-то типа habrahabr.ru/post/240543. И для предложенной красоты места там скорее всего не останется.
MS объясняет это тем, что уже выпущенные обновления на момент их централизованного выхода корпоративным пользователям окажутся обкатаны на обычных пользователях.
Что-то не очень понял. При этом для обычных пользователей Windows по-прежнему платная?
Моя лучшая догадка:
1. Microsoft запрограммировал какой-то большой кусок Android runtime на дотнете
2. При публикации APK в Windows Store скорее всего будет происходить трансляция байткода Java/Dalvik/whatever в CIL + прикручивание п.1 в виде библиотеки.
Т.е. в итоге там будет получаться самый обычный пакет, как если бы его изначально делали на дотнете.
В императивном программировании порядок выполнения (порядок исполнения, порядок вычислений) — это способ упорядочения инструкций программы в процессе ее выполнения.
Очевидно что CSS — это декларативное, а не императивное программирование.
А более конкретно, Windows Mobile (ага, именно так теперь называется Windows для телефонов и планшетов с диагональю менее 8 дюймов) будет включать в себя слой Android runtime, который позволит исполнять существующие приложения Android без специальных переделок. В противоположность проекту Islandwood, где разработчикам нужно специальным образом пересобрать приложение, чтобы оно запустилось на Windows, Astoria по идее будет работать с любым старым APK (при условии, что этот APK использует только те API, которые предоставляет Astoria). Единственное, что потребуется от разработчика — опубликовать приложение в Windows Store.
во главу угла проекта надо ставить финансовую сторону, так как без неё программист не сможет просто работать, так как не ясно откуда возьмутся деньги ему на ЗП.
Ваш подход будет замечательно работать для команд, состоящих из одного человека. В случае команд из двух и более людей начинаются проблемы :-)
Программист будет работать в компании только до тех пор, пока ему нравится работать в этой компании. «Нравится» состоит, например, из: размера зарплаты, гламурности офиса, «веры» в востребованность своей работы, профессионального роста и ещё пары десятков очевидных и не очень очевидных вещей.
Программист (если это «профессиональный программист», а не «студент») стабильно работает с примерно одной и той же производительностью — у него нет перепадов типа «я вчера запилил десяток фич, поэтому следующие 3 дня работать не буду, а после этого буду работать вполсилы». Например, программист может делать одну фичу в неделю. Стабильно.
Бизнес (основанный на программировании) будет существовать только до тех пор, пока появляются новые фичи. Если в команде есть 5 программистов, можно теоретически ожидать 5 фич в неделю. Так вот задача бизнеса — продавать эти самые «5 фич в неделю» таким образом, чтобы в итоге и на зарплату хватило, и компы новые можно было купить, и ещё осталось «на всякий случай». И конечно же речь не идёт о том, чтобы взять «хочу столько денег», поделить на «есть столько фич» и пытаться продавать фичи по той цене, которая получилась. Где-то здесь появляется «суть бизнеса» :-)
Я наверное неудачно выразился. Хочется на разные куски кода делать отдельные обсуждения. Но не в масштабе «а завтра обсудим XXX», а в масштабе — у нас есть 30 минут чтобы посмотреть на вот этот класс, давайте отдельно пообсуждаем каждый из вот этих трёх его методов. Посмотрите например на Upsource — у них сделано очень похоже на комментарии в Google Drive: можно выделить кусок кода и прокомментировать. Было бы интересно вместо комментариев мелким шрифтом где-то сбоку видеть это на половину экрана огромными буквами — в виде чата.
При всём уважении к проделанной работе, идея именно такой функциональности мне кажется немного странной. По-моему с таким же успехом можно попросить всех участников на половину экрана открыть нужный файл, а на вторую половину — чат. Предложу вот такие юзкейзы «как юзер»:
1. Я хочу обсуждать конкретные части кода — как минимум строчки «от» и «до»
2. Я хочу обсуждать конкретные части кода — методы, классы (конечно, с привязкой к конкретному языку)
3. Я хочу чтобы обсуждение можно было привязать к конкретному куску кода
4. Я хочу чтобы обсуждение можно было в итоге запостить как issue на Github — после того как все наобсуждались
Чтобы понять позицию «твой код никого не интересует», надо подойти со стороны бизнеса: зарабатывание денег, выплата ЗП своим сотрудникам, уплата налогов, в общем, с точки зрения доходов/расходов компании или отдельно взятого человека. Например, утверждение «идеальный код — залог успешного бизнеса» может казаться логичным, но с точки зрения доходов/расходов далеко не всегда истинно.
Задача бизнеса — обеспечить поток денег. Задача инженеров — обеспечить поток фич. Эти 2 задачи безусловно «как-то» связаны друг с другом, но не обязательно так, как описано в статье. Если бизнес завязывает поток денег напрямую на поток фич — это проблема бизнеса, а не инженеров.
С порядком ваших оценок совершенно согласен, но обычно либа — не одна, отсюда и неделя вместо одного дня. А даже если вдруг одна, она обычно тянет за собой ещё парочку, а их сборка — опять же на ваших плечах.
Самая большая проблема C++ — это отсутствие менеджера пакетов. В Go/Rust/Python/Ruby/JavaScript/Java/.NET вы находите подходящие инструменты и решаете задачу (ну может с Go и Rust я немного погорячился). В C++ вы находите подходящие инструменты, неделю их подключаете, ещё неделю пишете README по настройке dev энвайронмента, и только после этого решаете задачу.
Тематическая книга Александреску вышла в 2001 году.
Это не проблема отсутствия времени: чаще всего проблема в самодисциплине и расстановке приоритетов. Без в/о и постоянной работы точно так же можно дотянуть до пенсии (при условии, что есть где жить и что есть).
Стоило рассмотреть вариант устройства на работу в геймдев контору. Ваша полуготовая игра очень хорошо помогла бы на собеседовании. Это позволило бы и постоянный источник дохода иметь и, что более важно, возможность общаться с более опытными коллегами. Не говоря уже о том, чтобы посмотреть «как это делают другие».
Наличие в/о действительно очень редко как-то связано с толковостью специалиста, но есть интересные нюансы: например, без образования практически невозможно «уехать».
Вы пока не сделали ничего для того, чтобы заработать деньги. Улучшение кода, графики и геймплея не приближает вас к зарабатыванию денег, как бы ни хотелось в это верить. Вот если сейчас бросите заниматься перфекционизмом и попробуете на игре заработать хотя бы 1 доллар — это будет огромный шаг в правильную сторону.
Графика выглядит очень интересно, но немного не понятно ради чего тут было уходить из университета.
1. Статья называется «Сажаем контроллеры на диету». Т.е. про контроллеры.
2. В начале статьи сказано: «При использовании MVC в Android, Activity или Fragment является контроллером». Т.е. я в первую очередь смотрю на код Activity, потому что сказано, что «статья про контроллеры, а контроллеры — это Activity».
Посмотрел — прокомментировал. Интересно было бы посмотреть, насколько чистый код получился бы, если бы вы канонично связь model->view делали через Loader, а controller->model через IntentService. У меня есть искренние сомнения по поводу того, что от предложенного подхода в итоге что-то останется.
Что-то не очень понял. При этом для обычных пользователей Windows по-прежнему платная?
1. Microsoft запрограммировал какой-то большой кусок Android runtime на дотнете
2. При публикации APK в Windows Store скорее всего будет происходить трансляция байткода Java/Dalvik/whatever в CIL + прикручивание п.1 в виде библиотеки.
Т.е. в итоге там будет получаться самый обычный пакет, как если бы его изначально делали на дотнете.
В CSS нет логики в том смысле, что «дизайн CSS не очень логичный».
Википедия учит нас:
Очевидно что CSS — это декларативное, а не императивное программирование.
Arstechnica подсказывает:
Ваш подход будет замечательно работать для команд, состоящих из одного человека. В случае команд из двух и более людей начинаются проблемы :-)
Программист будет работать в компании только до тех пор, пока ему нравится работать в этой компании. «Нравится» состоит, например, из: размера зарплаты, гламурности офиса, «веры» в востребованность своей работы, профессионального роста и ещё пары десятков очевидных и не очень очевидных вещей.
Программист (если это «профессиональный программист», а не «студент») стабильно работает с примерно одной и той же производительностью — у него нет перепадов типа «я вчера запилил десяток фич, поэтому следующие 3 дня работать не буду, а после этого буду работать вполсилы». Например, программист может делать одну фичу в неделю. Стабильно.
Бизнес (основанный на программировании) будет существовать только до тех пор, пока появляются новые фичи. Если в команде есть 5 программистов, можно теоретически ожидать 5 фич в неделю. Так вот задача бизнеса — продавать эти самые «5 фич в неделю» таким образом, чтобы в итоге и на зарплату хватило, и компы новые можно было купить, и ещё осталось «на всякий случай». И конечно же речь не идёт о том, чтобы взять «хочу столько денег», поделить на «есть столько фич» и пытаться продавать фичи по той цене, которая получилась. Где-то здесь появляется «суть бизнеса» :-)
1. Я хочу обсуждать конкретные части кода — как минимум строчки «от» и «до»
2. Я хочу обсуждать конкретные части кода — методы, классы (конечно, с привязкой к конкретному языку)
3. Я хочу чтобы обсуждение можно было привязать к конкретному куску кода
4. Я хочу чтобы обсуждение можно было в итоге запостить как issue на Github — после того как все наобсуждались
1. Можно смотреть код
2. Можно чатиться
3. Единственное что связывает код с чатом — возможность цитировать куски кода
?
Задача бизнеса — обеспечить поток денег. Задача инженеров — обеспечить поток фич. Эти 2 задачи безусловно «как-то» связаны друг с другом, но не обязательно так, как описано в статье. Если бизнес завязывает поток денег напрямую на поток фич — это проблема бизнеса, а не инженеров.