1. Я думаю можно взять любые скриптовые миграции из RoR, Django, или Doctrine и писать миграции через него, если база достаточно простая. Под монстров типо Oracle наверняка существуют аналогичные инструменты для однообразного дампа в обычные файлы.
2. Данные нужно бекапить, тут не нужна система контроля версий. В тех же скриптовых языках есть инструменты для фикстур — данные, для дальнейшего тестирования. Это уже flow конкретно взятого проекта.
1. У одной и той же БД на разных клиентах в разных системах и при разных настройках текст дампа может быть принципиально разным.
2. Как можно забрать изменения в базе от других, если есть только полный дамп — не совсем понятно. Добавить строчку в программе — это не одно и тоже, что добавить строчку в БД (нужен отдельный INSERT)
Правки должны выглядеть в виде скрипта-апдейта к какому-то эталонному состоянию БД, а не просто каждый раз дамп БД. Нужно делать что-то типа вот такого, как минимум: habrahabr.ru/post/121265/
Возможно вам будет удобно реорганизовать столь обьемную историю в набор субмодулей, тогда разработчики могли бы работать именно с частями проекта (частями истории проекта). Если есть какие-то бинарные данные в репе и их действительно необходимо по тем или иным причинам держать в связке с кодом (например, запакованные чем-то вроде themida билды ехешников, которые нужно проверять на множестве машин/сборок/виртуалок, чтобы все было всегда пучком и софт третьей стороны не ломал наши сборки + сюда же по каждой такой сборке свой отчет по тестированию) — то это можно и нужно реорганизовывать. Есть авторские эскизы, по которым ведется работа/обсуждение — также, в отдельную папку/субмодуль. Есть сомнение что на каждую задачу каждый разработчик обязан таскать полностью весь проект.
Если это недопустимо и проект полностью неразборный — то так или иначе придется подумать над упрощением работы с ним, рано или поздно это выльется в замедление процесса разработки = потерю денег и конкурентного преимущества в скорости роста.
Вы немного путаете понятия: git отлично умеет работать с частичной историей. Он не умеет работать с удалённой историей (то есть с той историей, которая не у вас локально хранится, а где-то на сервере).
VCS — для неуверенных в себе. Профессионалы не используют VCS. Они не используют версии. Они сразу пишут финальный вариант. Без ошибок. Без тестов и опросов пользователей.
Для использования git submodule еще небольшие настройки нужно добавить: git config --global core.attributesfile "~/.gitattributes"
И в сам .gitattributes добавить запись: .gitmodules eol=lf
Не совсем так
i18n.commitencoding действительно указывает в какой кодировке был введён комментарий, но текст комментария вносится в объект коммита без изменений, а в заголовок объекта пишется кодировка комментария.
Я не уверен только влияет-ли как-то этот заголовок на имя коммитера и автора.
Так что в какой кодировке вводится комментарий — абсолютно всё равно, главное что-бы Git знал какая это кодировка. Git log и некоторые другие комманды используют этот заголовок что-бы во время вывода на экран производить перекодирование в нужную кодировку (в UTF-8 или в ту, которая указана в i18n.logoutputencoding). Но только для форматов oneline, short, medium, full, fuller. Если задать формат явно, например --format=%s, то первая строка комментария будет выведена без изменений.
А вот с именами файлов беда. Если коротко — то лучше не пользоваться русскими именами файлов если с репозиторием будут работать под разными операционными системами.
1. Цель. Чтобы научиться бегать, надо бегать, а не заучивать тексты про бег. Я уж не говорю про несвязные пары слов. То же с проектированием, дифференциированием, программированием и чем угодно ещё.
2. Создавать себе трудности. И преодолевать их сначала с помощью учителя (что бы ни означало это слово — сейчас учитель не обязательно тот, у кого в трудовой книжке написано это слово), а потом и самостоятельно. Движение от зоны актуального развития через зону ближайшего развития к зоне перспективного развития (это термины).
3. Без труда не вынешь рыбку из пруда. В переводе на термины — нагружение до утомления плюс восстановление до суперкомпенсации.
4. В здоровом теле — здоровый мозг.
5. Жизнь надо организовать так, чтобы учёба в институте не мешала образованию.
поддержка сообществом
продвижение гигантами IT-индустрии
легкость освоения
зрелость технологии
А почему не: скорость разработки, сложность поддержки, багоёмкость, отзывчивость работы, наличие стандартной библиотеки, адаптивность?
мы в Программе «Единая фронтальная система» выбрали основным фреймворком для разработки React.
Звучит как "в качестве средства передвижения мы выбрали шины мишлен" :-) Говорите уж честно: вы создали свой уникальный фреймворк, в котором скомпоновали несколько известных библиотек, несколько неизвестных, нескольких велосипедов и кучу связующего их между собой кода.
для React существует огромное количество написанных элементов UI, библиотек для управления состоянием приложения и других модулей.
К сожалению, количество слабо коррелирует с качеством. Что лучше: 10 разношёрстных библиотек управления состоянием или одна, но идеально стыкующаяся с остальными компонентами фреймворка?
На мой взгляд, здесь не нужны дополнительные комментарии: зачем разрабатывать на фреймворке, который убьет много времени на освоение?
А сколько вы убили времени на освоение экосистемы Реакта и подгонку выбранного вами набора библиотек друг ко другу?
О том, как создать приложение на реакте за один вечер, Николай рассказал на конференции.
Я там увидел лишь создание мёртвой формы и вывод таблички с рандомными данными. Ни обработчиков действий пользователя, ни сетевых запросов, ни индикаторов загрузки, ни локализации, ни настроек для переиспользования в разных местах, ни дизайна в конце концов. Сколько займёт времени добавление всего этого?
Зачастую он показывает некоторую интерактивную картинку, которую можно пощупать.
Это называется "макет". MVP же должен реализовывать как минимум один бизнес процесс от начала и до конца. Иначе его Value = 0.
так и есть. Я это всегда пытаюсь донести до хипстеров, которые с пеной у рта доказывают какие этот протонмейл или румынский хостинг немца защищенные.
Только свой собственный хостинг на дедике будет гарантированно защищенным, когда дедик отрубает питание при открытии корпуса сервера.
com + net — под контролем Verisign = USA, DNS в Германии, где тотальная слежка.
protonmail.com
protonmail.com. 339 IN MX 5 mail.protonmail.ch.
protonmail.com. 339 IN MX 10 mail1.protonmail.ch.
protonmail.com. 938 IN NS ns2.protonmail.ch.
protonmail.com. 938 IN NS ns1.protonmail.ch.
com — под контролем Verisign = USA, так что новый главный домен взамен .ch отпадает. Следом швейцария… с осени 2016 года в швейцарии новый закон, который должен свести на нет плюшки швейцарии и врыть их хостинг ее в одну яму с германией.
Кто же остался? Прогнивший евросоюз. Законы и доступе к информации очень и очень классные и гарантируют удар по жбану, если кто-то получает доступ к вашим данным. Не все страны, конечно следуют ему. Домен — .eu/.fr, сервера во франции или румынии.
Там поднимается почтовый сервис, которые через `blablabla sieve gpg` шифрует письма паблик ключами, которые были залиты на сервер, благо гайдов полно. На диске используется ecryptfs.
Мне вот сейчас 27 и взбрело в голову стать программистом, да еще и без высшего образования. Уже третий месяц пошел, как занимаюсь этим. И уже предвкушаю каково будет проходить собеседование на позицию junior'а и работать бок о бок с тем, кому 18. Но это, знаете, игры разума. В том смысле, что действительно проблемой может стать предвзятость некоторых работодателей. И да, чем дальше, тем грустнее, что самому уже не 18. Но и все, других хоть сколько-нибудь существенных проблем я не вижу.
Вот смотрите, снижение скорости когнитивных процессов обычно происходит годам к 50 — 60. И тут есть как негативные факторы, вроде болезней или образа жизни, когда большую часть времени человек проводит, почесывая пах, и развалившись на диване, так и позитивные, вроде постоянного самообразования, поддержания физического тонуса упражнениями. То есть, влияние возраста преувеличено.
С другой стороны, беспокоить может вопрос о скорости обучения и как следствие постоянное отставание от «молодых и дерзких». Но это, опять таки, следствие когнитивных искажений. Если условно разделить программирование на компетенции, позволяющие поддерживать актуальный уровень профессионализма, то можно отметить следующие навыки и знания: во-первых, знание синтаксиса и API тех или иных библиотек языка, во-вторых, умение моделировать абстракции и связи между ними (читай архитектуру), ну и в третьих, способность поддерживать эти знания в актуальном состоянии.
Первое достигается практикой и, неожиданно, чтением документации. И практикой. Тут возраст вообще не играет никакой роли.
Со вторым дела обстоят чуть сложнее, в том плане, что все вроде бы понятно, но что делать, не вполне ясно. Фактически это означает чтение книг о тех или иных парадигмах программирования, алгоритмах, паттернах и антипаттернах. Применение этого на практике. Ну и чтобы все это ложилось на благодатную почву, имеет смысл удобрить ее Computer Science. Благо, информации — куча. Я, например, просвещаюсь на Лекториум. И самое радостное, парадигм, да и вообще фундаментальных знаний, конечное количество. А важно тут вот что, если человек не просто сидел, почесывая пах, а на протяжении жизни хоть как-то самообразовывался, то у него не возникнет проблем с освоением абстракций и парадигм. Способность мозга к моделированию не линейная, а кумулятивная. Для примера, попробуйте открыть учебник по любому предмету класс эдак за 7. Фактически, это брошюра на 150 страниц, которая читается за вечер. Чему там учить целый год? Но это особенность нашей психики, когда человек моложе, его «банк моделей» не такой большой, чем старше человек, тем у него больше возможностей к опосредованному осознанию. Это чем-то напоминает алиасы. Когда мозг собирает понимание новой модели, через кусочки уже понятых, через аналогии. Мне, например, именно расширение своих способностей к абстрактному мышлению и моделированию, представляется самым трудным. Но и тут, я вижу определенные плюсы в том, что меня не накрывает гормональной волной, которая толкает совокуплять все что движется (по крайней мере не так сильно как в 18). То есть, позволяет выстроить процесс самообучения более последовательно.
Ну, и как только синтаксис будет изучен, а новая книжка с описанием архитектуры будет восприниматься легко даже при чтении по диагонали, для поддержки знаний и навыков необходимо будет всего лишь читать draft'ы, обсуждения на git'е, ну и хабр, естественно.
Единственное, что может потребовать усилий, так это убедить сотрудника hr отдела, что вы более чем подходите для этой должности. И если ни ваша компетентность, ни низкая мобильность в плане смены места работы, ни ваша предрасположенность к открытому обсуждению сложностей не могут перевесить чашу весов конкретного hr'а, то стоит задуматься, а действительно ли вы хотите работать в такой компании, и уж точно не стоит экстраполировать один случай предвзятости на все компании.
Сейчас мне это представляется так, но тут может сказаться недостаток опыта.
2. Данные нужно бекапить, тут не нужна система контроля версий. В тех же скриптовых языках есть инструменты для фикстур — данные, для дальнейшего тестирования. Это уже flow конкретно взятого проекта.
2. Как можно забрать изменения в базе от других, если есть только полный дамп — не совсем понятно. Добавить строчку в программе — это не одно и тоже, что добавить строчку в БД (нужен отдельный INSERT)
Правки должны выглядеть в виде скрипта-апдейта к какому-то эталонному состоянию БД, а не просто каждый раз дамп БД. Нужно делать что-то типа вот такого, как минимум: habrahabr.ru/post/121265/
git-scm.com/book/ru/Инструменты-Git-Подмодули
Если это недопустимо и проект полностью неразборный — то так или иначе придется подумать над упрощением работы с ним, рано или поздно это выльется в замедление процесса разработки = потерю денег и конкурентного преимущества в скорости роста.
В конце концов, никому не нужно «все». Коллективы могут иметь непересекающиеся наборы бранчей и только «центр» хранит все актуальные ветки.
git config --global core.attributesfile "~/.gitattributes"И в сам .gitattributes добавить запись:
.gitmodules eol=lfПравда здесь (http://wwarlock.blogspot.com/2009/06/utf-8-cygwin-17.html) для CygWin.
chcp 65001и cmd.exe уже в utf-8i18n.commitencoding действительно указывает в какой кодировке был введён комментарий, но текст комментария вносится в объект коммита без изменений, а в заголовок объекта пишется кодировка комментария.
Я не уверен только влияет-ли как-то этот заголовок на имя коммитера и автора.
Так что в какой кодировке вводится комментарий — абсолютно всё равно, главное что-бы Git знал какая это кодировка. Git log и некоторые другие комманды используют этот заголовок что-бы во время вывода на экран производить перекодирование в нужную кодировку (в UTF-8 или в ту, которая указана в i18n.logoutputencoding). Но только для форматов oneline, short, medium, full, fuller. Если задать формат явно, например --format=%s, то первая строка комментария будет выведена без изменений.
А вот с именами файлов беда. Если коротко — то лучше не пользоваться русскими именами файлов если с репозиторием будут работать под разными операционными системами.
2. Создавать себе трудности. И преодолевать их сначала с помощью учителя (что бы ни означало это слово — сейчас учитель не обязательно тот, у кого в трудовой книжке написано это слово), а потом и самостоятельно. Движение от зоны актуального развития через зону ближайшего развития к зоне перспективного развития (это термины).
3. Без труда не вынешь рыбку из пруда. В переводе на термины — нагружение до утомления плюс восстановление до суперкомпенсации.
4. В здоровом теле — здоровый мозг.
5. Жизнь надо организовать так, чтобы учёба в институте не мешала образованию.
А почему не: скорость разработки, сложность поддержки, багоёмкость, отзывчивость работы, наличие стандартной библиотеки, адаптивность?
Звучит как "в качестве средства передвижения мы выбрали шины мишлен" :-) Говорите уж честно: вы создали свой уникальный фреймворк, в котором скомпоновали несколько известных библиотек, несколько неизвестных, нескольких велосипедов и кучу связующего их между собой кода.
К сожалению, количество слабо коррелирует с качеством. Что лучше: 10 разношёрстных библиотек управления состоянием или одна, но идеально стыкующаяся с остальными компонентами фреймворка?
А сколько вы убили времени на освоение экосистемы Реакта и подгонку выбранного вами набора библиотек друг ко другу?
Я там увидел лишь создание мёртвой формы и вывод таблички с рандомными данными. Ни обработчиков действий пользователя, ни сетевых запросов, ни индикаторов загрузки, ни локализации, ни настроек для переиспользования в разных местах, ни дизайна в конце концов. Сколько займёт времени добавление всего этого?
Это называется "макет". MVP же должен реализовывать как минимум один бизнес процесс от начала и до конца. Иначе его Value = 0.
Только свой собственный хостинг на дедике будет гарантированно защищенным, когда дедик отрубает питание при открытии корпуса сервера.
tutanota.com
com + net — под контролем Verisign = USA, DNS в Германии, где тотальная слежка.
protonmail.com
com — под контролем Verisign = USA, так что новый главный домен взамен .ch отпадает. Следом швейцария… с осени 2016 года в швейцарии новый закон, который должен свести на нет плюшки швейцарии и врыть их хостинг ее в одну яму с германией.
Кто же остался?
Прогнившийевросоюз. Законы и доступе к информации очень и очень классные и гарантируют удар по жбану, если кто-то получает доступ к вашим данным. Не все страны, конечно следуют ему. Домен — .eu/.fr, сервера во франции или румынии.Там поднимается почтовый сервис, которые через `blablabla sieve gpg` шифрует письма паблик ключами, которые были залиты на сервер, благо гайдов полно. На диске используется ecryptfs.
Вот смотрите, снижение скорости когнитивных процессов обычно происходит годам к 50 — 60. И тут есть как негативные факторы, вроде болезней или образа жизни, когда большую часть времени человек проводит, почесывая пах, и развалившись на диване, так и позитивные, вроде постоянного самообразования, поддержания физического тонуса упражнениями. То есть, влияние возраста преувеличено.
С другой стороны, беспокоить может вопрос о скорости обучения и как следствие постоянное отставание от «молодых и дерзких». Но это, опять таки, следствие когнитивных искажений. Если условно разделить программирование на компетенции, позволяющие поддерживать актуальный уровень профессионализма, то можно отметить следующие навыки и знания: во-первых, знание синтаксиса и API тех или иных библиотек языка, во-вторых, умение моделировать абстракции и связи между ними (читай архитектуру), ну и в третьих, способность поддерживать эти знания в актуальном состоянии.
Первое достигается практикой и, неожиданно, чтением документации. И практикой. Тут возраст вообще не играет никакой роли.
Со вторым дела обстоят чуть сложнее, в том плане, что все вроде бы понятно, но что делать, не вполне ясно. Фактически это означает чтение книг о тех или иных парадигмах программирования, алгоритмах, паттернах и антипаттернах. Применение этого на практике. Ну и чтобы все это ложилось на благодатную почву, имеет смысл удобрить ее Computer Science. Благо, информации — куча. Я, например, просвещаюсь на Лекториум. И самое радостное, парадигм, да и вообще фундаментальных знаний, конечное количество. А важно тут вот что, если человек не просто сидел, почесывая пах, а на протяжении жизни хоть как-то самообразовывался, то у него не возникнет проблем с освоением абстракций и парадигм. Способность мозга к моделированию не линейная, а кумулятивная. Для примера, попробуйте открыть учебник по любому предмету класс эдак за 7. Фактически, это брошюра на 150 страниц, которая читается за вечер. Чему там учить целый год? Но это особенность нашей психики, когда человек моложе, его «банк моделей» не такой большой, чем старше человек, тем у него больше возможностей к опосредованному осознанию. Это чем-то напоминает алиасы. Когда мозг собирает понимание новой модели, через кусочки уже понятых, через аналогии. Мне, например, именно расширение своих способностей к абстрактному мышлению и моделированию, представляется самым трудным. Но и тут, я вижу определенные плюсы в том, что меня не накрывает гормональной волной, которая толкает совокуплять все что движется (по крайней мере не так сильно как в 18). То есть, позволяет выстроить процесс самообучения более последовательно.
Ну, и как только синтаксис будет изучен, а новая книжка с описанием архитектуры будет восприниматься легко даже при чтении по диагонали, для поддержки знаний и навыков необходимо будет всего лишь читать draft'ы, обсуждения на git'е, ну и хабр, естественно.
Единственное, что может потребовать усилий, так это убедить сотрудника hr отдела, что вы более чем подходите для этой должности. И если ни ваша компетентность, ни низкая мобильность в плане смены места работы, ни ваша предрасположенность к открытому обсуждению сложностей не могут перевесить чашу весов конкретного hr'а, то стоит задуматься, а действительно ли вы хотите работать в такой компании, и уж точно не стоит экстраполировать один случай предвзятости на все компании.
Сейчас мне это представляется так, но тут может сказаться недостаток опыта.