Потому что руки смысла слов не понимают. Если хотите задействовать мышечную память для ассоциативного запоминания (это когда вы смысл поняли не до конца), надо писать от руки.
Ну, почему? Как по мне, то набор руками, очень даже – ничего! Я ведь писал эту программу для себя, с целью выучить язык. Процесс идет, особенно, с учетом того, что: «Я уже в том возрасте, когда можно говорить, что я уже не в том возрасте!». Другое дела, что много времени уходит на подготовку обучающих данных.
Если вы имеет в виду, что:
для производства «сырного продукта» необязательно иметь в наличии какие-либо молочные продукты
в смысле:
Существующие учебники, не построенные на принципах сопоставитики, не предназначены ни для двоечника из Парижа, ни для отличника из Красноярска
то, с вами можно поспорить. У всех то, ведь, «различные представления о прекрасном». Например, мне, допустим, интересны двуязычные учебники, а вместо «самоучитель + аудио», я хотел бы иметь «самоучитель + видео». Вот, скажем, пример, в html-формате, французского учебника грамматики на английском языке:
При этом мы выигрываем дважды, осваиваем язык как таковой и, заодно, изучаем его грамматику, которая, часто выглядит более естественной и простой, по сравнению с её описанием, например, на русском языке, где, иногда, «за деревьями не видно леса».
Что касается "проговаривая вслух озвученные фразы", то непонятно, что вы имели ввиду.
Да, повтор за диктором. В моей обучающей программе, работа со звуком интерактивная, но, можно просто включить режим «Видео» и смотреть двуязычный текст и слушать его озвучку. Но, это же можно делать и вне программы, просто просматривая, несколько раз, любимый видосик, вроде:
Опять же: увидев слона один раз, вам не надо будет по-отдельности запоминать странные формы его хобота, хвоста и пр. Полное, целостное, невербальное понимание смысла слова, фразы врезается в память навечно.
Хочется верить, но где примеры? Вот, вариант запомнить «навечно» для прикольных фраз:
я быстро понял, что вручную такие схемы рисовать — это боль. Даже если у тебя всего пара десятков квадратиков и стрелочек с подписями, это всё разрастается и становится неуправляемым.
Да, я тоже с подобным столкнулся. Поэтому, быстро наваял скрипт на Питоне, который по заданным параметрам строит нужные диаграммы, например, для будущей статьи на «Хабре» по поводу модульной архитектуры моего приложения. Вот пример, такой блок-схемы:
Git для пет-проектов нужен не потому что «так принято», а потому что он избавляет от ручного копирования папок.
А разве это проблема? «Shift+F5» и папка скопирована!
С ним можно спокойно экспериментировать в ветках и возвращаться к рабочей версии за секунду.
А как он интегрируется с инструментами разработки? VS C++ / Python / «1С» или, там, расширения для «Хрома»? Управление Гитом – через командную строку, только? Какая там база данных используется?
Ну и бэкап на Гитхабе бесплатный — если ноут упадёт - код не пропадёт.
Если санкции против РФ введут на Гитхабе (говорят, одно время даже вводили), что тогда? Вот я довольно долго пользовался сайтом codeproject.com, но, сейчас там авария на их серверах, многие ценные архивы утеряны. Кое-что сохранилось на моем компьютере, а у них, уже, нет.
И потом, кто вам мешает хранить важную информацию на флэшках или внешних носителях? Всяко надежней будет облачных сервисов.
А когда привыкнете, потом в команде не придётся учиться с нуля.
Вы бы хоть пару ключевых картинок демонстрирующих работу Гит, для абсолютных новичков, типа меня, показали бы. А то все слова, слова. Я, конечно, могу и сам всё найти, но пока смысла не увижу – буду лениться. Понятная картинка могла бы поспособствовать этому. Как говориться: «Лучше один раз потрогать, чем сто раз увидеть».
А командная работа меня не греет. Всегда программировал один. Вместе, будет только лишняя конкуренция и никому не нужные конфликты, особенно, с моими «представлениями о прекрасном», которые, несколько, отличаются от новомодных и общепринятых.
Если перенести всё это без очистки, новая система захлебнётся в шумах.
Не захлебнется!
Не уверен, что вы правильно расставляете акценты.
Миграция — это не переезд, а реновация. Нельзя переехать в новую квартиру со старыми тараканами. Задача аналитика — убедить заказчика выкинуть хлам до переезда, а не надеяться, что новая система сама «переварит» мусор.
Похоже, вы сами не занимались переносом данных из одной системы в другую. Слишком уж поверхностные суждения, причем со точки зрения: «советы постороннего».
Хорошо, убедили вы заказчика, разрешил он вам «выкинуть хлам до переезда», а кто всем этим будет заниматься? Именно «очисткой» данных и собственно их «переносом» («миграцией») из одной системы в другую?
Судя по контексту статьи этим должен заниматься «аудит» (т.е., привлечение некой внешней фирмы) и команда программистов, тоже, скорее, внешних, Для «внутренних» программистов, то бишь, сотрудников искомой фирмы, аудит не нужен, они сами в курсе всех проблем по старой системе. Другое дело, если они не знают новую систему, тогда могут не справится. Однако и «внешние» программисты почти наверняка будут не курсе по старой системе, особенно, если она не стандартная, скажем, самописная конфигурация для «1С77», которую надо выгрузить в типовую конфу на «1С8х».
Поэтому, все эти сентенции:
Запустите скрипты
Выгрузите списки «подозрительных» записей и передайте их владельцам данных
Пропишите алгоритмы: как объединять дубликаты
Выгрузка «истории» в «архивное хранилище»
выглядят, скажем мягко, несерьезно.
Во-первых, почему вы решили, что у фирмы есть лишнй бюджет на перевнедрение работающей системы? Если денег много, что проще внедрить новую систему с нуля, т.е., просто ввести туда начальные остатки и актуальные справочники, которые можно распечатать на бумагу в старой системе. А потом, просто вводить текущие документы. Если же, нужно перенести исторические данные, то это всегда отдельный большой вопрос, который нужно решать не так, как вы предлагаете. Попутно возникает вопрос о переобучении персонала.
Во-вторых, почему вы думает, что главное это «лишние» данные, а код для переноса – нечто второстепенное?
На самом деле, всё, как раз, наоборот. «Старые» данные в хорошей базе данных не проблема. А если они не корректны, то виновата сама система, соответственно ее программист, который позволил вводить дубликаты и не использовал надежную валидацию и контроль ошибок. Конечно, в этом случае, исходные данные нужно корректировать в рамках старой системы, безотносительно, от переезда их в новую.
Далее, ключевым моментом в переносе данных являются технология, алгоритмы и инструменты для их миграции. Это самая сложная работа, особенно, для несовместимого программного обеспечения. Всё остальное это «мелочи по сравнению с Мировой Революцией». Причем, настолько, что иной раз дешевле напрячь «девочек», которые введут всю новую информацию с «бумаги» во внедряемую программу.
Для «восьмерки» («1С8х») существует типовая конфигурация «КД» («Конвертация данных»). Она позволяет, более-менее, автоматизировано переносить данные из одной типовой конфы, в другую. Но, если исходная, либо целевая конфигурация не вполне типовая (например, программист «1С» прикасался к ней своими шаловливыми ручками), то сразу же возникнут «нюансы».
Третий момент, нередко, фирмы поручают всю работу одному своему программисту, который «и швец и жнец и на дуде игрец», естественно за одну зарплату.
Например, в свое время, меня взяли в производственную фирму с условием внедрить подходящую систему учета для предприятия. Дали денег, я купил все более-менее подходящие программы учета, которые были на рынке, тогда. Но, ни одна из них не «взлетела». Ибо фирма «1С» вообще ваяет конфы по принципу: «Нам с ними не работать!». Что делать? «Взялся за гуж – не говори, что не дюж!». Пришлось, в срочном порядке, в режиме «нон-стоп» (12 часов в день без выходных и праздников) писать свою конфигурацию. К счастью, на предыдущей работе у меня уже были трехлетние (не законченные) наработки, которые мне очень сильно помогли. Через три месяца первый прототип конфигурации заработал. Там даже нормальных отчетов не было, только генерация текстовой информации вместо них.
Потом встал вопрос о наполнении моей «системы» данными. Данные были в районном вычислительном центре, который вел учет для нас. Работали они тоже на самописке, но на «FoxPro». Причем, наши данные они нам отдавать не хотели, так как лишались клиента. Пришлось напрячь госструктуры – отдали, но, естественно, это были почти бесполезные dbf-файлы с непонятной структурой.
Однако, делать нечего, структуру большей части этих данных я выяснил. Потом, их надо было перенести в мою программу. Написал собственные обработки – перенес. Потом, «вылизывание» этих дынных вместе с девочками-бухгалтерами. Совместно – «вылизали».
Система официально вошла в строй. Районным вычислительным центром мы пользоваться перестали. Однако, еще полгода работал в авральном режиме, все появляющиеся проблемы надо было решать в режиме реального времени. Более-менее, расслабился только через два года. В данном случае это была 100%-но собственная конфигурация по учету и расчету заработной платы плюс собственная система учета рабочего времени на базе нетбуков, китайских считывателей RFID-карт доступа сотрудников и собственного драйвера на С++ для нее.
После чего приступил к разработке собственной конфигурации «Учет ресурсов», которую уже начал внедрять. Однако, пришла новая главбухша и перевнедрила ее на типовую конфигурацию «ПУБ» («Производство, Услуги и Бухгалтерия» для Украины). Просто, она хорошо знала «ПУБ», а мою конфу не знала, хотя типовая была, на мой взгляд, менее удобной. Зато мою «Зарплату» перевнедрить не смогла, даже на ее старом предприятии, три программиста ваяли собственный вариант из «ЗиК» («Зарплата и Кадры»), два года, т.е., типовые «зарплаты» не годились от слова «совсем».
Поскольку я живу в ЛНР, то когда появилась непризнанная Республика, учет весь надо было переделывать и мою «Зарплату» и производственный учет от главбухши.
Однако, самое сложное началось, когда ЛНР вошла в состав России. Поскольку, лишних «денюх» у фирмы не было, нужно было искать самое дешевое решение. С «Зарплатой» проблем не возникло, я довольно быстро адаптировал ее алгоритмы к российскому законодательству. А для производственного учета выбрал конфу «ПУБ» для РФ.
Несмотря, на похожие названия украинская «ПУБ» (относительно просто адаптированная под ЛНР) оказалась слабо совместимой с российской «ПУБ». Прежде всего, из-за разных Планов Счетов. А российского плана счетов у нас никто не знал, даже новый главбух. Вот и как переносить остатки и документы при такой неопределенности?
Я сделал встроенный, в конфигурацию, конвертер, в котором бухгалтера могли устанавливать соответствие между разными Планами Счетов. После чего можно было запустить обработку, которая делает автоматом перегрузку данных из старой конфы в новую. Причем, этот процесс можно было повторять неоднократно, перезаписывая «неправильные» документы «правильными».
Все это, конечно, было очень сложно, но других вариантов у меня не было. Как бы то, ни было, процесс по переходу из одной государственности в другую шел успешно. Жаль только, что на взлете фирму «подстрелили», т.е., ликвидировали по политическим мотивам (вроде, как не слишком выгодной она была).
Т.е., я хочу сказать, что все эти разговоры «вообще»: о «миграции», «скриптах», «дубликатах», «архивах» и тому подобное, выглядят нелепо с точки зрения реального опыта.
Например, данные по заработной плате у меня хранились в рабочей системе более, чем за двадцать лет. И совершенно не мешали! Потому, что были «правильно» организованны. А собственный движок базы данных «1С77» я заменил движком «Visual FoxPro», которые подключался к dbf / cdx-файлам «семерки» напрямую. При этом «1С77» был DDE-сервером, а VFP – DDE-клиентом, что увеличило производительность базы данных в 15 раз, вполне достаточную для предприятия. А сама конфа «крутилась» на терминал-сервере фирмы.
А если бы мы пошли по вашей схеме, то фирму, наверняка, ликвидировали бы значительно раньше.
Ну, хорошо! Посмотрим на это дело вашими глазами. Вот вы говорите: «Git держит все эти ваши копии проекта и итерации в одной базе данных». В какой? Хотя, лучше спросить: Зачем мне хранить итерации проекта в базе данных? Что это мне дает? Я понимаю, базе можно послать любой запрос и она даст «любой» ответ. Но, это будут только куски кода или весь проект целиком? В первом случае мне это неудобно, ибо привык воспринимать файлы с программами целиком. А, во втором – бессмысленно, я и так вижу свои итерации в отдельных каталогах.
Потом, как это влияет на оформление кода и как происходит взаимодействие с инструментами разработки? Т.е., добавляются ли метаданные в код? Меняется ли мой стиль оформления, поскольку, судя, по опенсорсу на Гитхабе, все используют «неправильную» стилизацию программного текста. Точнее, она мне просто не нравится. Ни в С++, ни в Питоне. Поэтому, предпочитаю собственное оформление.
В том же VS C++ как нужно устанавливать взаимодействие с Гитом? А в Питоне, особенно, когда я не использую никакие IDE для него? Как там с компиляцией и запуском на выполнение?
А есть еще расширения под старые версии Хрома, поскольку только там можно обходить современные ограничения для доступа к сайтам (классика: затруднение работы блокировшиков рекламы, загрузи данных с сайтов и т.п.). Как туда «прилепить» Гит? И нужно ли, когда сами скрипты, например, по обходу капчи, помещаются на экране целиком?
Далее, вот я сейчас экспериментирую с модульной структурой проекта. По сути, использую собственную концепцию. На первое место здесь встают вопросы архитектуры приложения, что сильно влияет на сам процесс программирования. Это уже не просто версии, откаты и «накаты», это постоянные изменения всей структуры проекта. Поможет ли мне здесь Гит? Не уверен, скорее, он просто будет путаться под ногами, мешая программированию.
Да, вы можете сказать, что на все вопросы дают ответы Ютуб, Интернет-1.0 или Интренет-2.0 (то бишь, ИИ-сервисы) плюс документация. Согласен, дают! Но, какой у меня стимул изучать все это? Только потому, что:
Профессиональное владение Git-ом сильно упрощает процесс управления кодом проекта, независимо от количества программистов вовлечённых в проект.
Возможно, но у меня и так нет сложностей в «процессе управления кодом проекта». Все отлично управляется и без Гита! А вот, если такие сложности возникнут, то тогда – да, появится стимул смотреть в его сторону. Как, например, появился интерес начать осваивать Питон, не потому, что он «моден», а потому, что для подготовки и обработки данных, в которых появилась острая необходимость, он гораздо лучше, того же С++.
А так, я не отрицаю пользы систем контроля версий. Но, в этом Мире есть много хороших инструментов, однако, если можно ограничиться минимумом из них, то зачем осваивать максимум? Впрок? Только, может и не пригодится. Я много что делал впрок в молодости, но, пригодились только считанные проценты.
Спасибо, за оценку! В том-то и ограничение у ИИ, что ему важно быстро дать результат, не важно, какой. А человеку надо, чтобы решение было хорошим и «красивым», если не сейчас, то в будущем.
Со стороны выглядит как "свой велосипед на квадратных колесах"
И что из этого следует? Устыдиться и бежать бегом делать «как все»? Тогда будет похоже на манипулирование. Достаточно сказать «фи» или «фу» и всё, товарищ начинает плясать под твою дудку. Классная, между прочим, идея. Иногда работает.
Однако, на серьезных людей такая аргументация не действует. А другой, похоже, у вас нет.
Проект – один, итерации разные. В каждой из них есть doc-файл, с описанием изменений. Просматриваю эти файлы и выбираю нужную итерацию либо для рефакторинга, либо как прототип для другого проекта.
Как по мне – вполне нормально. Вы можете использовать Гит, кто вам мешает? А мне нравится мой вариант. Я, ведь, таким образом, написал уже не одну программу, но, необходимости что-либо менять здесь – не вижу.
Кроме того, для каждой итерации скомпилированы бинарники. Иногда, проще запустить и посмотреть их, чем читать текст в описаниях.
Специально посмотрел пару книг. Да, тире там длиннее, чем «среднее», но, короче, чем длинное, в варианте ИИ. Поэтому, в книгах оно смотрится «норм». А в компьютерных текстах я предпочитаю стандартный «вордовский» вариант.
Я бы только добавила, что важен не только объем усилий, но и их направление: иногда дело не в том, что сделал мало, а в том, что нужен другой способ движения к цели – можно остановиться, пересобрать подход и уточнить для себя, к какому именно результату хочется прийти.
Вполне разумно и здраво!
Пример, на уровне написания статьи. Сначала выбираешь один заголовок и определенный путь ее оформления. Потом, в процессе, с удивлением, обнаруживаешь, что выбранный метод, который сам придумал, по факту, не работает. А половина статьи уже написана. Что делать? Ровно то, что вы говорите, по сути – изменить заголовок статьи и ее логику.
Скажем, для конкретики, я озадачился выяснением структуры словарных статей в озвученных, живым голосом, онлайн-словарях. Задача – извлечь текст, с сохранением его структуры, и звук, для создания, допустим, обучающих видео, вроде озвученных популярных глаголов с их переводами либо html-книг для соответствующих примеров использования.
Сразу, вопрос, в каком виде хранить извлекаемые данные, чтобы не терять их структуру (без структуры можно просто сохранить текст из html-страницы в буфер обмена)? Я думал, сначала, что в виде списка пар, первый элемент которых – это список всех тегов для конечного (текстового) значения (т.е., полная ветвь в html-лереве, от корня до листа), а второй – конечное значение (то бишь, простой текст).
Но, оказалось, что этот путь, хотя, в принципе, и работоспособный, но, в целом, не эффективный, в связи с потерей информации (я игнорировал закрывающие теги). Если же их использовать, то уже лучше, но нет смысла, тогда, хранить список путей этого дерева. Лучше, сразу применять html-дерево в удобном виде, например, после «красивого» форматирования его, с помощью BeautifulSoup.prettify() в Питоне.
Однако, отступы там – в виде одного пробела, а не табулятора, а лидирующие пробелы в конечном тексте – искажают формат.
В итоге, ко второму моему удивлению, работоспособной оказалась примитивизация текстового дерева (после применения prettify()). Т.е., тупое удаление всех начальных пробелов для всех строк «дерева». А этот формат получается тривиально, без использования библиотек Питона. Нужно просто вставить переводы строк до и после всех угловых скобок и удалить пустые строки. Идея, оказалась, – супер!
Причем, используя это сверх-примитивное представление html-дерева, легко написать собственный вариант функции prettify(), уже без пробоем оригинальной версии, что я и сделал. И, главное, то же самое представление вполне годится для структурированной обработки конечного текста или другими словами, извлечение текста из онлайн-словарей с сохранением их структуры.
Сейчас я заканчиваю скрипт, выполняющий эту работу. После чего, можно будет уже использовать эти данные для создания обучающих видео, книг либо данных для моей обучающей программы.
Короче говоря, статья продолжает «писаться», но уже другая :) .
P.S. Ну и чтобы «два раза не вставать», добавлю, что «способ движения к цели» может быть не важным, когда стоит другая задача – выбор направления движения. У древних философов была сентенция: «Цель – это Ничто! А Путь движения к Цели – это всё!». Раньше, я очень удивлялся ей, а теперь, думаю, что в этой фразе что-то есть.
Для версионирования – итерации. Беру прототип и добавляю туда какой-то локальный функционал. Работает? Хорошо! Делаю копию проекта и работаю уже с ней. В предыдущей итерации описываю в doc-файле, что там реализовано, какие возникли проблемы и что собираюсь делать дальше. И так, небольшими порциями, логически изменяемого функционала, двигаюсь от одной итерации к другой. Если возникает «затык», что бывает регулярно, просто возвращаюсь к предыдущей, рабочей версии проекта и начинаю все заново.
Переносимость обеспечиваю настройкой файлов проекта для Visual Studio C++ (с использованием WTL). Предпочитаю старые версии «Студии», как более привычные и легкие (на недостаток функциональности не жалуюсь). На работе была 2010-я, дома – 2013-я. В самом проекте присутствуют обе версии конфигурационных файлов, которые запускаю, в зависимости от ситуации.
Если на Гитхабе либо codeproject.com (сейчас этот сайт, после аварии на своих серверах – «лежит») имеется подходящий прототип на более высокой версии VS C++, то, стараюсь адаптировать этот код так, чтобы он работал, хотя бы на 2013-й версии. Чего, нередко, удается добиться. Если же нет, не страшно, ищу другой прототип.
Таки образом, без Гита я вполне обходился и обхожусь и, пока, не уверен, что он мне вообще когда-нибудь понадобится.
Какая «миссия»? Написать программу и выучить язык (последнее из нереализованного)? Миссия это когда: «Сталин-2.0 строит Социализм-2.0 в СССР-2.0». Главный посыл – качество результата определяет количество затраченных усилий. Что вполне «имеет место быть» даже на бытовом уровне.
За всю жизнь я ни разу не сталкивался с длинным тире, только в последний год, когда ИИ, реально, пришел в наш дом, оттого и раздражают они сильно.
Средние тире преобразуются автоматически из минусов (которые в два раза короче) в Ворде. А Ворд, по факту, стал определять нашу грамматику. Чтобы писать грамотно, надо, чтобы не было явных ошибок в «народном» редакторе.
Пишите комменты, как вы публикуете, может быть даже есть какие-то собственные наработки по этой теме?
Я предпочитаю статьи с результатами и ссылками на собственные архивы. Структура должна быть простая:
Введение.
Часть Первая. Результирующая.
Часть Вторая. Техническая.
Выводы.
Изображения должны быть содержательными, а не прикола ради, просто потому, что эти картинки нравятся автору.
Код в статьях, предпочитаю не публиковать, максимум, строчек десять, не больше. Просто ссылаюсь на собственный архив с кодом и описанием его работы.
Не использовать длинные тире, только «средние». Не использовать горизонтальные разделительные линии, которые так любят ИИ. И вообще не использовать оформление от ИИ, оно слишком одиозно. Да и стиль текста там – «не живой». Лучше, с ошибками, но свое.
Привет! Спасибо, за подробное изложение своей точки зрения.
Я думаю тут вопрос больше должен ставиться так: подразумевает ли твой пет проект дальнейшее использование совместно с кем-то. Ведь Git берет свое начало именно с этого)
Скорее, нет, чем да. Но, даже если, вдруг, такая необходимость возникнет, то, опять же, предпочел бы собственный путь.
На примере моей обучающей программы, реализованной, с большим трудом, в первой версии, при определении ее архитектуры для второй версии, которой я начал заниматься, я предполагаю использовать следующее:
Допускаем наличие архитектора ПО и членов команды программистов.
Архитектор создает прототип проекта, в котором разрабатываемые модули (по сути,, классы) имеют чисто формальные реализации., т.е., набор публичных функций с пустым телом. При этом, вызовы этих публичных функций в главном модуле приложения (для проектов на C++ / WTL это будет CMainFrame), за разработку которого отвечает архитектор, должны быть зафиксированы явно (скажем, в обработчиках сообщений либо в функциях потоков).
Этот проект, с «пустыми» модулями (классами) компилируется, но, по сути, ничего, особо не делает. Только отображение главного окна, его полного меню, но без реальной работы (разве что, просто вывод мессаджбокса с указанием выбранного пункта меню), тулбара и статусбара.
Этот прототип проекта раздается всем членам команды, с указанием, кому, какой модуль (класс) развивать, т.е., заменять пустые тела функций их реальным содержимым. При необходимости, программисты-исполнители могут добавлять приватные функции и данные, на свое собственное усмотрение.
При завершении работы над модулем, программист отправляет архитектору (это может быть и удаленная работа) свою полную реализацию класса, за который он ответственен.
Архитектор, делает замену формального модуля на реальный и осуществляет общее тестирование. При необходимости, вносит изменения в работу команды.
Принятый, в первом приближении, реальный модуль может стать доступным для всех членов команды и тестировщиков.
Если реальный модуль обновляется, то его новая версия замещает старую, путем простой замены файлов.
Задача архитектора состоит в том, чтобы эта схема, либо аналогичная, принятая всеми членами команды, работала.
Как-то так.
Соответственно, если эксперимент по имитации командной работы, при создании второй версии моей программы, покажет свою эффективность, то продолжу использовать этот метод, иначе буду смотреть в сторону Гита либо еще чего-то в этом роде.
Но думаю не будет лишним делать через Git, как минимум для возможности отката до определенного состояния своего изначального кода или экспериментов или тестов в другой ветке, плюс используя удаленные репозитории ты можешь значительно облегчить себе жизнь, если тебе надо быстро перенести свои наработки на другую машину.
Но, у меня и так проблем не возникало. Например, при создании графической обертки для консольного загрузчика любимых видосиков с «народного» видеохостинга ( https://habr.com/ru/articles/955838/ ), у меня получилось 24 итерации для, в принципе, не слишком сложной программы. Поэтому, «откатываться» можно куда угодно, причем логически, а не по временным меткам.
«Удаленные репозитории» для меня – экзотика, с которой не хочется иметь дело, только локальные, только хардкор!
Перенос с машины на машину тоже не проблема. На работе у меня была одна операционная система и версия VS C++, дома – другие, однако, спокойно, переносил каждый день с помощью «флэшнет», пока была в этом необходимость.
«Итерационно-модульное программирование» - это же, по сути, и есть то, что Git формализует: итерации = коммиты, модули = ветки. Только Git ещё и запоминает каждый шаг
У меня нет необходимости запоминать «каждый шаг». Думаю, это лишнее. Я делаю упор на программную логику, а там важнее не шаги, а изменения состояния работы программы.
Рекомендую все-таки изучить такой инструмент как Git(кстати придумал его гениальный человек), там найдешь много интересного, например git revert.
Верю, что «гениальный»! Только мне этого мало, куда, важнее, смысл. Пока, смысла в Гите я, для себя, лично, откровенного говоря, не вижу.
Ни там, ни здесь я так и не понял, нужен ли Git для разработки индивидуальных пет-проектов? «Там» доказывали – что нужен, но, когда возражал, что «лично мне – нет», почему-то обижались, естественно, с минусованием, как же без него доказать свою правоту?
По крайней мере, я использую альтернативу – «итерационно-модульное» программирование, которое меня вполне устраивает. Если бы я увидел нормальные аргументы в пользу Гит, то мог бы поэкспериментировать в этом направлении, но, пока, таких аргументов нет, поэтому, остаемся все, при своем собственном мнении, как всегда.
Итоговый текст написан моим ИИ-коллегой на основе нашего с ним разговора, я его прочитал и опубликовал.
Статья, как ни странно, мне понравилась, ожидал худшего.
Естественный язык – это новый язык программирования
Не думаю, что акцент надо делать на языке, естественный язык не в меньшей степени алгоритмичен, что и искусственный. Я бы даже сказал больше – языки программирования это просто формализованные подмножества естественного языка.
И у этого языка, как у любого языка программирования, есть свои требования: Точность формулировок Умение устранять неоднозначность Способность декомпозировать сложную мысль на части Понимание контекста, который ты передаёшь И, пожалуй, самое сложное – осознание момента, когда ты сам ещё не понял чего хочешь
Ну, вот! Вы и сами это подтверждаете. Фактически, вы формализуете естественный язык, после чего он становиться похож на искусственный, только и всего.
Те, кто всегда был "гуманитарием" — внезапно оказываются ближе к новому языку, чем многие технари.
Вот уж не уверен, от слова «совсем»! Гуманитарии не имеют никаких преимуществ, ибо у них, «насквозь», отсутствует абстрактное мышление. Абстрактное мышление хорошо развито, допустим, у математиков. Однако, у них нет «базы», т.е., связи с «Землей». Скажем, на математиков в МГУ «поступают либо в 17 лет, либо никогда!». Но, после Университета, они живут в «облаках» и реальную жизнь знают плохо. Лучше, если они закончат второй ВУЗ, например, технический, в рамках работы на предприятии, либо в Научном Центре, который свяжет их с технической «прозой жизни». Как говорят физики-теоретики: «Любая теория верна до тех пор, пока не будет опровергнута!», а физики-экспериментаторы добавляют: «Прибор нужен не «в принципе» (т.е. в теории), в кожухе (т.е., на практике)».
Отсюда следует, что преимущества в будущем будут иметь люди с двумя высшими образованиями: научным и техническим (если еще будет гуманитарное, то, хуже точно не будет).
учиться теперь нужно совсем другому
Но, не общению с машиной (хотя это было давно предсказано, например, я, в 1981-м году, на военных офицерских сборах, читал философское эссе: «Логика диалога или дилогика», в котором автор предсказывал будущее за диалогом естественного и искусственного разума), а, скорее, развивать собственное мышление.
Дело в том, главное в целеполагании развития – это наши «хотелки», которые могут быть очень смутными и неопределенными. И время, пока созреет идея до полной ее формализации или хотя бы пространного артикулирования, типа: «Сделайте мне красиво!» или «Пойди туда, не знаю куда, принеси то, не знаю что!», может, иногда, составить целые годы.
Чем в этом случае, нам поможет ИИ? Он лучше нас знает, чего мы хотим? На эту тему даже анекдот есть: «Митинг Партии Женщин: – Кто мы? – Женщины! – Чего мы хотим? – Не знаем! – Когда мы этого хотим? –Прямо, сейчас! И много!».
Если ИИ научатся желать за нас, зачем им тогда «кожаные мешки»? То ли ИИ-ям искать биологические тела для себя, то ли «мешкам» имплантировать себе в мозги ИИ-шные чипы.
Короче от «дилогики» мы, пока, ни куда не денемся. На ближайшее время симбиоз человека с ИИ-сервисами – неизбежен. Поэтому, человеку надо развивать в себе все человеческое, а ИИ-ям – ИИ-шное! При этом, «естественный язык программирования», здесь, совершенно не причем.
Выберите одну цель по формуле «Мне нужно за [срок] научиться [X], чтобы сделать [Y] в [контексте]», ограничьте источники до двух-трёх, учитесь по мере необходимости и поставьте себе честный критерий, когда будет «достаточно хорошо».
Я бы предложил другую идею: «Стремитесь добиться перехода «количества» (затраченных вам усилий) в «качество» (конечный результат)». А если нового «качества» еще нет, значит, просто было мало используемого «количества».
Эта формула универсальна, классики не дадут соврать. И она, действительно, работает. Только результат должен быть принципиально достижимым и четко обозначенным.
Например: «Получить второе полное дневное высшее образование на мехмате МГУ.». Затраченные усилия: «Самостоятельная подготовка к вступительным экзаменам и, вообще, повышение своего уровня в математике, участие в физико-математическом конкурсе журнала «Квант» для школьников, добиться не только заочных, но и очных подготовительных курсов в Москве и, самое главное, обязательная отработка по распределению, после первого ВУЗа, в областном НИИ – четыре года.». Результат – выполнено! МГУ успел закончить до распада СССР.
Второй пример. Появились персональные компьютеры, налоговая стала требовать компьютерную отчетность, а собственное предприятие – автоматизации процессов и научных исследований. Путного ПО, в то время, практически, не существовало. Надо было ваять собственное, но, как, если за окном смог, то бишь, туман, – непонятно (как в анекдоте: «– Сегодня, смог. – Поздравляю, сэр!»).
Сел за ПК (самые первые в нашем городе) и поставил цель: «Не только освоить программирование и компиляторы, но и создать, как минимум, собственную систему учета для предприятия». Три года потратил на эксперименты (не считая времени на оформление научных статей, по тематике фирмы). В конце концов, я такую систему создал и даже внедрил на паре производственных предприятий. Что и кормило меня двадцать лет.
Третий пример. Поставил цель: «Создание собственной обучающей системы для изучения иностранных языков и выучить, хотя бы два-три из них». Программу (первую версию) уже создал, обучающие демо-данные, для нее, плюс видео с двуязычными субтитрами и html-тексты (или книги) – тоже. Но, до полного освоения, пока, французского языка, дело еще дошло, по банальной причине: «Количество еще не перешло в качество». Поэтому, продолжаем работу. Попутно, по ходу дела, пишу статьи на «Хабр» :) .
Ладно, посмотрю на досуге, какой-нибудь Ютуб. Всё равно, из чужих объяснений я не могу уловить особого смысла в Гите.
Ну, почему? Как по мне, то набор руками, очень даже – ничего! Я ведь писал эту программу для себя, с целью выучить язык. Процесс идет, особенно, с учетом того, что: «Я уже в том возрасте, когда можно говорить, что я уже не в том возрасте!». Другое дела, что много времени уходит на подготовку обучающих данных.
Если вы имеет в виду, что:
в смысле:
то, с вами можно поспорить. У всех то, ведь, «различные представления о прекрасном». Например, мне, допустим, интересны двуязычные учебники, а вместо «самоучитель + аудио», я хотел бы иметь «самоучитель + видео». Вот, скажем, пример, в html-формате, французского учебника грамматики на английском языке:
При этом мы выигрываем дважды, осваиваем язык как таковой и, заодно, изучаем его грамматику, которая, часто выглядит более естественной и простой, по сравнению с её описанием, например, на русском языке, где, иногда, «за деревьями не видно леса».
Да, повтор за диктором. В моей обучающей программе, работа со звуком интерактивная, но, можно просто включить режим «Видео» и смотреть двуязычный текст и слушать его озвучку. Но, это же можно делать и вне программы, просто просматривая, несколько раз, любимый видосик, вроде:
Хочется верить, но где примеры? Вот, вариант запомнить «навечно» для прикольных фраз:
Да, я тоже с подобным столкнулся. Поэтому, быстро наваял скрипт на Питоне, который по заданным параметрам строит нужные диаграммы, например, для будущей статьи на «Хабре» по поводу модульной архитектуры моего приложения. Вот пример, такой блок-схемы:
А разве это проблема? «Shift+F5» и папка скопирована!
А как он интегрируется с инструментами разработки? VS C++ / Python / «1С» или, там, расширения для «Хрома»? Управление Гитом – через командную строку, только? Какая там база данных используется?
Если санкции против РФ введут на Гитхабе (говорят, одно время даже вводили), что тогда? Вот я довольно долго пользовался сайтом codeproject.com, но, сейчас там авария на их серверах, многие ценные архивы утеряны. Кое-что сохранилось на моем компьютере, а у них, уже, нет.
И потом, кто вам мешает хранить важную информацию на флэшках или внешних носителях? Всяко надежней будет облачных сервисов.
Вы бы хоть пару ключевых картинок демонстрирующих работу Гит, для абсолютных новичков, типа меня, показали бы. А то все слова, слова. Я, конечно, могу и сам всё найти, но пока смысла не увижу – буду лениться. Понятная картинка могла бы поспособствовать этому. Как говориться: «Лучше один раз потрогать, чем сто раз увидеть».
А командная работа меня не греет. Всегда программировал один. Вместе, будет только лишняя конкуренция и никому не нужные конфликты, особенно, с моими «представлениями о прекрасном», которые, несколько, отличаются от новомодных и общепринятых.
А почему бы не учить слова в контексте, например, набирая руками и проговаривая вслух озвученные фразы?
Не захлебнется!
Не уверен, что вы правильно расставляете акценты.
Похоже, вы сами не занимались переносом данных из одной системы в другую. Слишком уж поверхностные суждения, причем со точки зрения: «советы постороннего».
Хорошо, убедили вы заказчика, разрешил он вам «выкинуть хлам до переезда», а кто всем этим будет заниматься? Именно «очисткой» данных и собственно их «переносом» («миграцией») из одной системы в другую?
Судя по контексту статьи этим должен заниматься «аудит» (т.е., привлечение некой внешней фирмы) и команда программистов, тоже, скорее, внешних, Для «внутренних» программистов, то бишь, сотрудников искомой фирмы, аудит не нужен, они сами в курсе всех проблем по старой системе. Другое дело, если они не знают новую систему, тогда могут не справится. Однако и «внешние» программисты почти наверняка будут не курсе по старой системе, особенно, если она не стандартная, скажем, самописная конфигурация для «1С77», которую надо выгрузить в типовую конфу на «1С8х».
Поэтому, все эти сентенции:
Запустите скрипты
Выгрузите списки «подозрительных» записей и передайте их владельцам данных
Пропишите алгоритмы: как объединять дубликаты
Выгрузка «истории» в «архивное хранилище»
выглядят, скажем мягко, несерьезно.
Во-первых, почему вы решили, что у фирмы есть лишнй бюджет на перевнедрение работающей системы? Если денег много, что проще внедрить новую систему с нуля, т.е., просто ввести туда начальные остатки и актуальные справочники, которые можно распечатать на бумагу в старой системе. А потом, просто вводить текущие документы. Если же, нужно перенести исторические данные, то это всегда отдельный большой вопрос, который нужно решать не так, как вы предлагаете. Попутно возникает вопрос о переобучении персонала.
Во-вторых, почему вы думает, что главное это «лишние» данные, а код для переноса – нечто второстепенное?
На самом деле, всё, как раз, наоборот. «Старые» данные в хорошей базе данных не проблема. А если они не корректны, то виновата сама система, соответственно ее программист, который позволил вводить дубликаты и не использовал надежную валидацию и контроль ошибок. Конечно, в этом случае, исходные данные нужно корректировать в рамках старой системы, безотносительно, от переезда их в новую.
Далее, ключевым моментом в переносе данных являются технология, алгоритмы и инструменты для их миграции. Это самая сложная работа, особенно, для несовместимого программного обеспечения. Всё остальное это «мелочи по сравнению с Мировой Революцией». Причем, настолько, что иной раз дешевле напрячь «девочек», которые введут всю новую информацию с «бумаги» во внедряемую программу.
Для «восьмерки» («1С8х») существует типовая конфигурация «КД» («Конвертация данных»). Она позволяет, более-менее, автоматизировано переносить данные из одной типовой конфы, в другую. Но, если исходная, либо целевая конфигурация не вполне типовая (например, программист «1С» прикасался к ней своими шаловливыми ручками), то сразу же возникнут «нюансы».
Третий момент, нередко, фирмы поручают всю работу одному своему программисту, который «и швец и жнец и на дуде игрец», естественно за одну зарплату.
Например, в свое время, меня взяли в производственную фирму с условием внедрить подходящую систему учета для предприятия. Дали денег, я купил все более-менее подходящие программы учета, которые были на рынке, тогда. Но, ни одна из них не «взлетела». Ибо фирма «1С» вообще ваяет конфы по принципу: «Нам с ними не работать!». Что делать? «Взялся за гуж – не говори, что не дюж!». Пришлось, в срочном порядке, в режиме «нон-стоп» (12 часов в день без выходных и праздников) писать свою конфигурацию. К счастью, на предыдущей работе у меня уже были трехлетние (не законченные) наработки, которые мне очень сильно помогли. Через три месяца первый прототип конфигурации заработал. Там даже нормальных отчетов не было, только генерация текстовой информации вместо них.
Потом встал вопрос о наполнении моей «системы» данными. Данные были в районном вычислительном центре, который вел учет для нас. Работали они тоже на самописке, но на «FoxPro». Причем, наши данные они нам отдавать не хотели, так как лишались клиента. Пришлось напрячь госструктуры – отдали, но, естественно, это были почти бесполезные dbf-файлы с непонятной структурой.
Однако, делать нечего, структуру большей части этих данных я выяснил. Потом, их надо было перенести в мою программу. Написал собственные обработки – перенес. Потом, «вылизывание» этих дынных вместе с девочками-бухгалтерами. Совместно – «вылизали».
Система официально вошла в строй. Районным вычислительным центром мы пользоваться перестали. Однако, еще полгода работал в авральном режиме, все появляющиеся проблемы надо было решать в режиме реального времени. Более-менее, расслабился только через два года. В данном случае это была 100%-но собственная конфигурация по учету и расчету заработной платы плюс собственная система учета рабочего времени на базе нетбуков, китайских считывателей RFID-карт доступа сотрудников и собственного драйвера на С++ для нее.
После чего приступил к разработке собственной конфигурации «Учет ресурсов», которую уже начал внедрять. Однако, пришла новая главбухша и перевнедрила ее на типовую конфигурацию «ПУБ» («Производство, Услуги и Бухгалтерия» для Украины). Просто, она хорошо знала «ПУБ», а мою конфу не знала, хотя типовая была, на мой взгляд, менее удобной. Зато мою «Зарплату» перевнедрить не смогла, даже на ее старом предприятии, три программиста ваяли собственный вариант из «ЗиК» («Зарплата и Кадры»), два года, т.е., типовые «зарплаты» не годились от слова «совсем».
Поскольку я живу в ЛНР, то когда появилась непризнанная Республика, учет весь надо было переделывать и мою «Зарплату» и производственный учет от главбухши.
Однако, самое сложное началось, когда ЛНР вошла в состав России. Поскольку, лишних «денюх» у фирмы не было, нужно было искать самое дешевое решение. С «Зарплатой» проблем не возникло, я довольно быстро адаптировал ее алгоритмы к российскому законодательству. А для производственного учета выбрал конфу «ПУБ» для РФ.
Несмотря, на похожие названия украинская «ПУБ» (относительно просто адаптированная под ЛНР) оказалась слабо совместимой с российской «ПУБ». Прежде всего, из-за разных Планов Счетов. А российского плана счетов у нас никто не знал, даже новый главбух. Вот и как переносить остатки и документы при такой неопределенности?
Я сделал встроенный, в конфигурацию, конвертер, в котором бухгалтера могли устанавливать соответствие между разными Планами Счетов. После чего можно было запустить обработку, которая делает автоматом перегрузку данных из старой конфы в новую. Причем, этот процесс можно было повторять неоднократно, перезаписывая «неправильные» документы «правильными».
Все это, конечно, было очень сложно, но других вариантов у меня не было. Как бы то, ни было, процесс по переходу из одной государственности в другую шел успешно. Жаль только, что на взлете фирму «подстрелили», т.е., ликвидировали по политическим мотивам (вроде, как не слишком выгодной она была).
Т.е., я хочу сказать, что все эти разговоры «вообще»: о «миграции», «скриптах», «дубликатах», «архивах» и тому подобное, выглядят нелепо с точки зрения реального опыта.
Например, данные по заработной плате у меня хранились в рабочей системе более, чем за двадцать лет. И совершенно не мешали! Потому, что были «правильно» организованны. А собственный движок базы данных «1С77» я заменил движком «Visual FoxPro», которые подключался к dbf / cdx-файлам «семерки» напрямую. При этом «1С77» был DDE-сервером, а VFP – DDE-клиентом, что увеличило производительность базы данных в 15 раз, вполне достаточную для предприятия. А сама конфа «крутилась» на терминал-сервере фирмы.
А если бы мы пошли по вашей схеме, то фирму, наверняка, ликвидировали бы значительно раньше.
Ну, хорошо! Посмотрим на это дело вашими глазами. Вот вы говорите: «Git держит все эти ваши копии проекта и итерации в одной базе данных». В какой? Хотя, лучше спросить: Зачем мне хранить итерации проекта в базе данных? Что это мне дает? Я понимаю, базе можно послать любой запрос и она даст «любой» ответ. Но, это будут только куски кода или весь проект целиком? В первом случае мне это неудобно, ибо привык воспринимать файлы с программами целиком. А, во втором – бессмысленно, я и так вижу свои итерации в отдельных каталогах.
Потом, как это влияет на оформление кода и как происходит взаимодействие с инструментами разработки? Т.е., добавляются ли метаданные в код? Меняется ли мой стиль оформления, поскольку, судя, по опенсорсу на Гитхабе, все используют «неправильную» стилизацию программного текста. Точнее, она мне просто не нравится. Ни в С++, ни в Питоне. Поэтому, предпочитаю собственное оформление.
В том же VS C++ как нужно устанавливать взаимодействие с Гитом? А в Питоне, особенно, когда я не использую никакие IDE для него? Как там с компиляцией и запуском на выполнение?
А есть еще расширения под старые версии Хрома, поскольку только там можно обходить современные ограничения для доступа к сайтам (классика: затруднение работы блокировшиков рекламы, загрузи данных с сайтов и т.п.). Как туда «прилепить» Гит? И нужно ли, когда сами скрипты, например, по обходу капчи, помещаются на экране целиком?
Далее, вот я сейчас экспериментирую с модульной структурой проекта. По сути, использую собственную концепцию. На первое место здесь встают вопросы архитектуры приложения, что сильно влияет на сам процесс программирования. Это уже не просто версии, откаты и «накаты», это постоянные изменения всей структуры проекта. Поможет ли мне здесь Гит? Не уверен, скорее, он просто будет путаться под ногами, мешая программированию.
Да, вы можете сказать, что на все вопросы дают ответы Ютуб, Интернет-1.0 или Интренет-2.0 (то бишь, ИИ-сервисы) плюс документация. Согласен, дают! Но, какой у меня стимул изучать все это? Только потому, что:
Возможно, но у меня и так нет сложностей в «процессе управления кодом проекта». Все отлично управляется и без Гита! А вот, если такие сложности возникнут, то тогда – да, появится стимул смотреть в его сторону. Как, например, появился интерес начать осваивать Питон, не потому, что он «моден», а потому, что для подготовки и обработки данных, в которых появилась острая необходимость, он гораздо лучше, того же С++.
А так, я не отрицаю пользы систем контроля версий. Но, в этом Мире есть много хороших инструментов, однако, если можно ограничиться минимумом из них, то зачем осваивать максимум? Впрок? Только, может и не пригодится. Я много что делал впрок в молодости, но, пригодились только считанные проценты.
Спасибо, за оценку! В том-то и ограничение у ИИ, что ему важно быстро дать результат, не важно, какой. А человеку надо, чтобы решение было хорошим и «красивым», если не сейчас, то в будущем.
И что из этого следует? Устыдиться и бежать бегом делать «как все»? Тогда будет похоже на манипулирование. Достаточно сказать «фи» или «фу» и всё, товарищ начинает плясать под твою дудку. Классная, между прочим, идея. Иногда работает.
Однако, на серьезных людей такая аргументация не действует. А другой, похоже, у вас нет.
Проект – один, итерации разные. В каждой из них есть doc-файл, с описанием изменений. Просматриваю эти файлы и выбираю нужную итерацию либо для рефакторинга, либо как прототип для другого проекта.
Как по мне – вполне нормально. Вы можете использовать Гит, кто вам мешает? А мне нравится мой вариант. Я, ведь, таким образом, написал уже не одну программу, но, необходимости что-либо менять здесь – не вижу.
Кроме того, для каждой итерации скомпилированы бинарники. Иногда, проще запустить и посмотреть их, чем читать текст в описаниях.
Специально посмотрел пару книг. Да, тире там длиннее, чем «среднее», но, короче, чем длинное, в варианте ИИ. Поэтому, в книгах оно смотрится «норм». А в компьютерных текстах я предпочитаю стандартный «вордовский» вариант.
Вполне разумно и здраво!
Пример, на уровне написания статьи. Сначала выбираешь один заголовок и определенный путь ее оформления. Потом, в процессе, с удивлением, обнаруживаешь, что выбранный метод, который сам придумал, по факту, не работает. А половина статьи уже написана. Что делать? Ровно то, что вы говорите, по сути – изменить заголовок статьи и ее логику.
Скажем, для конкретики, я озадачился выяснением структуры словарных статей в озвученных, живым голосом, онлайн-словарях. Задача – извлечь текст, с сохранением его структуры, и звук, для создания, допустим, обучающих видео, вроде озвученных популярных глаголов с их переводами либо html-книг для соответствующих примеров использования.
Сразу, вопрос, в каком виде хранить извлекаемые данные, чтобы не терять их структуру (без структуры можно просто сохранить текст из html-страницы в буфер обмена)? Я думал, сначала, что в виде списка пар, первый элемент которых – это список всех тегов для конечного (текстового) значения (т.е., полная ветвь в html-лереве, от корня до листа), а второй – конечное значение (то бишь, простой текст).
Но, оказалось, что этот путь, хотя, в принципе, и работоспособный, но, в целом, не эффективный, в связи с потерей информации (я игнорировал закрывающие теги). Если же их использовать, то уже лучше, но нет смысла, тогда, хранить список путей этого дерева. Лучше, сразу применять html-дерево в удобном виде, например, после «красивого» форматирования его, с помощью BeautifulSoup.prettify() в Питоне.
Однако, отступы там – в виде одного пробела, а не табулятора, а лидирующие пробелы в конечном тексте – искажают формат.
В итоге, ко второму моему удивлению, работоспособной оказалась примитивизация текстового дерева (после применения prettify()). Т.е., тупое удаление всех начальных пробелов для всех строк «дерева». А этот формат получается тривиально, без использования библиотек Питона. Нужно просто вставить переводы строк до и после всех угловых скобок и удалить пустые строки. Идея, оказалась, – супер!
Причем, используя это сверх-примитивное представление html-дерева, легко написать собственный вариант функции prettify(), уже без пробоем оригинальной версии, что я и сделал. И, главное, то же самое представление вполне годится для структурированной обработки конечного текста или другими словами, извлечение текста из онлайн-словарей с сохранением их структуры.
Сейчас я заканчиваю скрипт, выполняющий эту работу. После чего, можно будет уже использовать эти данные для создания обучающих видео, книг либо данных для моей обучающей программы.
Короче говоря, статья продолжает «писаться», но уже другая :) .
P.S. Ну и чтобы «два раза не вставать», добавлю, что «способ движения к цели» может быть не важным, когда стоит другая задача – выбор направления движения. У древних философов была сентенция: «Цель – это Ничто! А Путь движения к Цели – это всё!». Раньше, я очень удивлялся ей, а теперь, думаю, что в этой фразе что-то есть.
Для версионирования – итерации. Беру прототип и добавляю туда какой-то локальный функционал. Работает? Хорошо! Делаю копию проекта и работаю уже с ней. В предыдущей итерации описываю в doc-файле, что там реализовано, какие возникли проблемы и что собираюсь делать дальше. И так, небольшими порциями, логически изменяемого функционала, двигаюсь от одной итерации к другой. Если возникает «затык», что бывает регулярно, просто возвращаюсь к предыдущей, рабочей версии проекта и начинаю все заново.
Переносимость обеспечиваю настройкой файлов проекта для Visual Studio C++ (с использованием WTL). Предпочитаю старые версии «Студии», как более привычные и легкие (на недостаток функциональности не жалуюсь). На работе была 2010-я, дома – 2013-я. В самом проекте присутствуют обе версии конфигурационных файлов, которые запускаю, в зависимости от ситуации.
Если на Гитхабе либо codeproject.com (сейчас этот сайт, после аварии на своих серверах – «лежит») имеется подходящий прототип на более высокой версии VS C++, то, стараюсь адаптировать этот код так, чтобы он работал, хотя бы на 2013-й версии. Чего, нередко, удается добиться. Если же нет, не страшно, ищу другой прототип.
Таки образом, без Гита я вполне обходился и обхожусь и, пока, не уверен, что он мне вообще когда-нибудь понадобится.
Какая «миссия»? Написать программу и выучить язык (последнее из нереализованного)? Миссия это когда: «Сталин-2.0 строит Социализм-2.0 в СССР-2.0». Главный посыл – качество результата определяет количество затраченных усилий. Что вполне «имеет место быть» даже на бытовом уровне.
За всю жизнь я ни разу не сталкивался с длинным тире, только в последний год, когда ИИ, реально, пришел в наш дом, оттого и раздражают они сильно.
Средние тире преобразуются автоматически из минусов (которые в два раза короче) в Ворде. А Ворд, по факту, стал определять нашу грамматику. Чтобы писать грамотно, надо, чтобы не было явных ошибок в «народном» редакторе.
Я предпочитаю статьи с результатами и ссылками на собственные архивы. Структура должна быть простая:
Введение.
Часть Первая. Результирующая.
Часть Вторая. Техническая.
Выводы.
Изображения должны быть содержательными, а не прикола ради, просто потому, что эти картинки нравятся автору.
Код в статьях, предпочитаю не публиковать, максимум, строчек десять, не больше. Просто ссылаюсь на собственный архив с кодом и описанием его работы.
Не использовать длинные тире, только «средние». Не использовать горизонтальные разделительные линии, которые так любят ИИ. И вообще не использовать оформление от ИИ, оно слишком одиозно. Да и стиль текста там – «не живой». Лучше, с ошибками, но свое.
Привет! Спасибо, за подробное изложение своей точки зрения.
Скорее, нет, чем да. Но, даже если, вдруг, такая необходимость возникнет, то, опять же, предпочел бы собственный путь.
На примере моей обучающей программы, реализованной, с большим трудом, в первой версии, при определении ее архитектуры для второй версии, которой я начал заниматься, я предполагаю использовать следующее:
Допускаем наличие архитектора ПО и членов команды программистов.
Архитектор создает прототип проекта, в котором разрабатываемые модули (по сути,, классы) имеют чисто формальные реализации., т.е., набор публичных функций с пустым телом. При этом, вызовы этих публичных функций в главном модуле приложения (для проектов на C++ / WTL это будет CMainFrame), за разработку которого отвечает архитектор, должны быть зафиксированы явно (скажем, в обработчиках сообщений либо в функциях потоков).
Этот проект, с «пустыми» модулями (классами) компилируется, но, по сути, ничего, особо не делает. Только отображение главного окна, его полного меню, но без реальной работы (разве что, просто вывод мессаджбокса с указанием выбранного пункта меню), тулбара и статусбара.
Этот прототип проекта раздается всем членам команды, с указанием, кому, какой модуль (класс) развивать, т.е., заменять пустые тела функций их реальным содержимым. При необходимости, программисты-исполнители могут добавлять приватные функции и данные, на свое собственное усмотрение.
При завершении работы над модулем, программист отправляет архитектору (это может быть и удаленная работа) свою полную реализацию класса, за который он ответственен.
Архитектор, делает замену формального модуля на реальный и осуществляет общее тестирование. При необходимости, вносит изменения в работу команды.
Принятый, в первом приближении, реальный модуль может стать доступным для всех членов команды и тестировщиков.
Если реальный модуль обновляется, то его новая версия замещает старую, путем простой замены файлов.
Задача архитектора состоит в том, чтобы эта схема, либо аналогичная, принятая всеми членами команды, работала.
Как-то так.
Соответственно, если эксперимент по имитации командной работы, при создании второй версии моей программы, покажет свою эффективность, то продолжу использовать этот метод, иначе буду смотреть в сторону Гита либо еще чего-то в этом роде.
Но, у меня и так проблем не возникало. Например, при создании графической обертки для консольного загрузчика любимых видосиков с «народного» видеохостинга ( https://habr.com/ru/articles/955838/ ), у меня получилось 24 итерации для, в принципе, не слишком сложной программы. Поэтому, «откатываться» можно куда угодно, причем логически, а не по временным меткам.
«Удаленные репозитории» для меня – экзотика, с которой не хочется иметь дело, только локальные, только хардкор!
Перенос с машины на машину тоже не проблема. На работе у меня была одна операционная система и версия VS C++, дома – другие, однако, спокойно, переносил каждый день с помощью «флэшнет», пока была в этом необходимость.
У меня нет необходимости запоминать «каждый шаг». Думаю, это лишнее. Я делаю упор на программную логику, а там важнее не шаги, а изменения состояния работы программы.
Верю, что «гениальный»! Только мне этого мало, куда, важнее, смысл. Пока, смысла в Гите я, для себя, лично, откровенного говоря, не вижу.
Взаимно! :)
Недавно, была опубликована похожая статья: «Гид по Git – глазами бывшего джуна» в https://habr.com/ru/companies/surfstudio/articles/973304/ .
Ни там, ни здесь я так и не понял, нужен ли Git для разработки индивидуальных пет-проектов? «Там» доказывали – что нужен, но, когда возражал, что «лично мне – нет», почему-то обижались, естественно, с минусованием, как же без него доказать свою правоту?
По крайней мере, я использую альтернативу – «итерационно-модульное» программирование, которое меня вполне устраивает. Если бы я увидел нормальные аргументы в пользу Гит, то мог бы поэкспериментировать в этом направлении, но, пока, таких аргументов нет, поэтому, остаемся все, при своем собственном мнении, как всегда.
Статья, как ни странно, мне понравилась, ожидал худшего.
Не думаю, что акцент надо делать на языке, естественный язык не в меньшей степени алгоритмичен, что и искусственный. Я бы даже сказал больше – языки программирования это просто формализованные подмножества естественного языка.
Ну, вот! Вы и сами это подтверждаете. Фактически, вы формализуете естественный язык, после чего он становиться похож на искусственный, только и всего.
Вот уж не уверен, от слова «совсем»! Гуманитарии не имеют никаких преимуществ, ибо у них, «насквозь», отсутствует абстрактное мышление. Абстрактное мышление хорошо развито, допустим, у математиков. Однако, у них нет «базы», т.е., связи с «Землей». Скажем, на математиков в МГУ «поступают либо в 17 лет, либо никогда!». Но, после Университета, они живут в «облаках» и реальную жизнь знают плохо. Лучше, если они закончат второй ВУЗ, например, технический, в рамках работы на предприятии, либо в Научном Центре, который свяжет их с технической «прозой жизни». Как говорят физики-теоретики: «Любая теория верна до тех пор, пока не будет опровергнута!», а физики-экспериментаторы добавляют: «Прибор нужен не «в принципе» (т.е. в теории), в кожухе (т.е., на практике)».
Отсюда следует, что преимущества в будущем будут иметь люди с двумя высшими образованиями: научным и техническим (если еще будет гуманитарное, то, хуже точно не будет).
Но, не общению с машиной (хотя это было давно предсказано, например, я, в 1981-м году, на военных офицерских сборах, читал философское эссе: «Логика диалога или дилогика», в котором автор предсказывал будущее за диалогом естественного и искусственного разума), а, скорее, развивать собственное мышление.
Дело в том, главное в целеполагании развития – это наши «хотелки», которые могут быть очень смутными и неопределенными. И время, пока созреет идея до полной ее формализации или хотя бы пространного артикулирования, типа: «Сделайте мне красиво!» или «Пойди туда, не знаю куда, принеси то, не знаю что!», может, иногда, составить целые годы.
Чем в этом случае, нам поможет ИИ? Он лучше нас знает, чего мы хотим? На эту тему даже анекдот есть: «Митинг Партии Женщин: – Кто мы? – Женщины! – Чего мы хотим? – Не знаем! – Когда мы этого хотим? –Прямо, сейчас! И много!».
Если ИИ научатся желать за нас, зачем им тогда «кожаные мешки»? То ли ИИ-ям искать биологические тела для себя, то ли «мешкам» имплантировать себе в мозги ИИ-шные чипы.
Короче от «дилогики» мы, пока, ни куда не денемся. На ближайшее время симбиоз человека с ИИ-сервисами – неизбежен. Поэтому, человеку надо развивать в себе все человеческое, а ИИ-ям – ИИ-шное! При этом, «естественный язык программирования», здесь, совершенно не причем.
Я бы предложил другую идею: «Стремитесь добиться перехода «количества» (затраченных вам усилий) в «качество» (конечный результат)». А если нового «качества» еще нет, значит, просто было мало используемого «количества».
Эта формула универсальна, классики не дадут соврать. И она, действительно, работает. Только результат должен быть принципиально достижимым и четко обозначенным.
Например: «Получить второе полное дневное высшее образование на мехмате МГУ.». Затраченные усилия: «Самостоятельная подготовка к вступительным экзаменам и, вообще, повышение своего уровня в математике, участие в физико-математическом конкурсе журнала «Квант» для школьников, добиться не только заочных, но и очных подготовительных курсов в Москве и, самое главное, обязательная отработка по распределению, после первого ВУЗа, в областном НИИ – четыре года.». Результат – выполнено! МГУ успел закончить до распада СССР.
Второй пример. Появились персональные компьютеры, налоговая стала требовать компьютерную отчетность, а собственное предприятие – автоматизации процессов и научных исследований. Путного ПО, в то время, практически, не существовало. Надо было ваять собственное, но, как, если за окном смог, то бишь, туман, – непонятно (как в анекдоте: «– Сегодня, смог. – Поздравляю, сэр!»).
Сел за ПК (самые первые в нашем городе) и поставил цель: «Не только освоить программирование и компиляторы, но и создать, как минимум, собственную систему учета для предприятия». Три года потратил на эксперименты (не считая времени на оформление научных статей, по тематике фирмы). В конце концов, я такую систему создал и даже внедрил на паре производственных предприятий. Что и кормило меня двадцать лет.
Третий пример. Поставил цель: «Создание собственной обучающей системы для изучения иностранных языков и выучить, хотя бы два-три из них». Программу (первую версию) уже создал, обучающие демо-данные, для нее, плюс видео с двуязычными субтитрами и html-тексты (или книги) – тоже. Но, до полного освоения, пока, французского языка, дело еще дошло, по банальной причине: «Количество еще не перешло в качество». Поэтому, продолжаем работу. Попутно, по ходу дела, пишу статьи на «Хабр» :) .
Как-то так.