День девятьсот пятьдесят шестой. #Оффтоп
Вчера слушал очередную серию подкаста Dotnet Rocks про DDD. Сама по себе беседа была довольно интересной. В гостях были Steve "Ardalis" Smith и Julie Lerman.
Но заинтересовала меня другая вещь, которую они упомянули в начале разговора - OpenAI Codex. Не так давно я писал про утилиту Copilot в GitHub, которая генерирует код за вас. Идея в том, что вы пишете человеческим языком, что вы хотите сделать, а AI система генерирует код. Так вот OpenAI выпустили ролик, где демонстрируют, как это работает, и ролик просто взрывает мозг. Авторы за 8 минут создают полноценную (хотя и простенькую) аркадную игру, где космический корабль должен избегать столкновения с астероидом. Вся игра от начала до конца написана фразами вроде «Расположи астероид в случайном месте экрана» и «Пусть астероид двигается горизонтально и вертикально, отскакивая от границ экрана» (хотя, конечно, по-английски). После ввода каждой фразы система на лету генерирует JavaScript код и показывает результат его работы.
В общем, вот само видео. В нём нет никаких комментариев, но они и не нужны. https://www.youtube.com/watch?v=Zm9B-DvwOgw
А здесь ребята из OpenAI чуть подробнее, с комментариями, показывают, как работает Codex на нескольких примерах: страничка «Hello world», простая игра, плагин для MS Word.
Скайнет не за горами?
Вчера слушал очередную серию подкаста Dotnet Rocks про DDD. Сама по себе беседа была довольно интересной. В гостях были Steve "Ardalis" Smith и Julie Lerman.
Но заинтересовала меня другая вещь, которую они упомянули в начале разговора - OpenAI Codex. Не так давно я писал про утилиту Copilot в GitHub, которая генерирует код за вас. Идея в том, что вы пишете человеческим языком, что вы хотите сделать, а AI система генерирует код. Так вот OpenAI выпустили ролик, где демонстрируют, как это работает, и ролик просто взрывает мозг. Авторы за 8 минут создают полноценную (хотя и простенькую) аркадную игру, где космический корабль должен избегать столкновения с астероидом. Вся игра от начала до конца написана фразами вроде «Расположи астероид в случайном месте экрана» и «Пусть астероид двигается горизонтально и вертикально, отскакивая от границ экрана» (хотя, конечно, по-английски). После ввода каждой фразы система на лету генерирует JavaScript код и показывает результат его работы.
В общем, вот само видео. В нём нет никаких комментариев, но они и не нужны. https://www.youtube.com/watch?v=Zm9B-DvwOgw
А здесь ребята из OpenAI чуть подробнее, с комментариями, показывают, как работает Codex на нескольких примерах: страничка «Hello world», простая игра, плагин для MS Word.
Скайнет не за горами?
День девятьсот пятьдесят седьмой. #Оффтоп
Всех коллег с профессиональным праздником. И по этому поводу серия постов скорей для начинающих карьеру. У всех нас были взлёты и падения в процессе обучения и наверняка каждый хотя бы раз в жизни задумывался о том, что хорошо было бы знать какие-то вещи раньше.
Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру. Начало
1. Разработка ПО - это решение проблем.
Быть программистом - это гораздо больше, чем сидеть перед компьютером и беспорядочно нажимать кнопки на клавиатуре. Это означает решать множество реальных проблем и облегчать жизни людей. Если вы способны это делать, вы не пропадёте.
2. Золотое правило - планирование.
Каждый успешный проект начинается с тщательного планирования. Убедитесь, что вы определили цель, задачи, целевую аудиторию и т.д. Используйте ручку и бумагу или любой онлайн-инструмент для создания макетов и попытайтесь продумать чёткую схему того, как будет выглядеть ваше решение.
3. Написание кода должно быть последней фазой проекта.
Новичкам может показаться, что любой проект по большей части состоит из написания кода. На самом деле это просто техническая реализация планирования, которое было сделано ранее, а написание кода должно быть последним шагом в решении проблемы.
4. У вас всё под рукой.
Сейчас уже не 50-е и даже не 90-е, когда нужно было идти в библиотеку, чтобы изучить какую-то тему. Вся необходимая информация всегда под рукой. Используйте свой мозг и интернет.
5. Для программирования не требуется топового оборудования.
Ультрасовременный процессор, огромное количество оперативной памяти и 5 мониторов - всё это необязательно. Ноутбука среднего уровня более чем достаточно, чтобы начать работу.
6. Необязательно хорошо разбираться в математике.
Программирование часто ассоциируется с гениями с IQ 200+. Серьёзная математика может потребоваться в таких темах, как искусственный интеллект, робототехника, криптография и т.д., но основной массе разработчиков она не нужна.
7. Найти правильный набор инструментов непросто.
У каждого из нас разные предпочтения. Поэкспериментируйте с разными расширениями и настройками. Потребуется много времени, чтобы понять, что вам подходит, а что нет, и их все связать воедино. Но позже это будет очень полезно для вашей продуктивности.
8. Идеальное время - сейчас.
Сохранение полезной статьи или курса в закладках - это просто один из вариантов прокрастинации. Лучше всего прочитать статью или пройти курс сейчас.
9. Синхронизация делает вас мобильным.
Синхронизируйте все расширения и настройки браузера и IDE кода на каждой машине, на которой вы работаете. Это гарантирует, что вы будете работать в одной среде, где бы вы ни находились.
10. Есть несколько способов достижения цели.
Когда я начинал писать код, я думал, что логика в коде очень строгая и должна следовать определённому шаблону. На самом деле единственным ограничителем является синтаксис используемого языка.
11. Воспринимайте ошибки как уроки.
Если вы посмотрите любую историю успеха, вы обнаружите, что на самом деле она состоит из попыток, ошибок и новых попыток чуть менее, чем полностью. Настойчивость и любопытство – ключи к победе.
12. Важно найти свою нишу.
Блуждание от технологии к технологии ни к чему не приведёт. Определитесь со своими интересами и исследуйте доступные области, прежде чем углубляться в одну из них.
13. Интересуйтесь, почему всё работает.
Всегда пытайтесь открыть для себя то, что скрывается под капотом. Недостаточно видеть, как вещи каким-то волшебным образом работают.
14. Увлечение сторонними проектами полезно.
Когда дело доходит до сторонних проектов, выберите то, что вам действительно интересно. Это повысит вашу мотивацию, поскольку вы будете заботиться о конечном результате.
15. Это марафон, а не спринт.
Область разработки постоянно развивается, поэтому приготовьтесь к непрерывному обучению. Если начать слишком активно, вы быстро устанете.
Продолжение следует…
Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka
Всех коллег с профессиональным праздником. И по этому поводу серия постов скорей для начинающих карьеру. У всех нас были взлёты и падения в процессе обучения и наверняка каждый хотя бы раз в жизни задумывался о том, что хорошо было бы знать какие-то вещи раньше.
Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру. Начало
1. Разработка ПО - это решение проблем.
Быть программистом - это гораздо больше, чем сидеть перед компьютером и беспорядочно нажимать кнопки на клавиатуре. Это означает решать множество реальных проблем и облегчать жизни людей. Если вы способны это делать, вы не пропадёте.
2. Золотое правило - планирование.
Каждый успешный проект начинается с тщательного планирования. Убедитесь, что вы определили цель, задачи, целевую аудиторию и т.д. Используйте ручку и бумагу или любой онлайн-инструмент для создания макетов и попытайтесь продумать чёткую схему того, как будет выглядеть ваше решение.
3. Написание кода должно быть последней фазой проекта.
Новичкам может показаться, что любой проект по большей части состоит из написания кода. На самом деле это просто техническая реализация планирования, которое было сделано ранее, а написание кода должно быть последним шагом в решении проблемы.
4. У вас всё под рукой.
Сейчас уже не 50-е и даже не 90-е, когда нужно было идти в библиотеку, чтобы изучить какую-то тему. Вся необходимая информация всегда под рукой. Используйте свой мозг и интернет.
5. Для программирования не требуется топового оборудования.
Ультрасовременный процессор, огромное количество оперативной памяти и 5 мониторов - всё это необязательно. Ноутбука среднего уровня более чем достаточно, чтобы начать работу.
6. Необязательно хорошо разбираться в математике.
Программирование часто ассоциируется с гениями с IQ 200+. Серьёзная математика может потребоваться в таких темах, как искусственный интеллект, робототехника, криптография и т.д., но основной массе разработчиков она не нужна.
7. Найти правильный набор инструментов непросто.
У каждого из нас разные предпочтения. Поэкспериментируйте с разными расширениями и настройками. Потребуется много времени, чтобы понять, что вам подходит, а что нет, и их все связать воедино. Но позже это будет очень полезно для вашей продуктивности.
8. Идеальное время - сейчас.
Сохранение полезной статьи или курса в закладках - это просто один из вариантов прокрастинации. Лучше всего прочитать статью или пройти курс сейчас.
9. Синхронизация делает вас мобильным.
Синхронизируйте все расширения и настройки браузера и IDE кода на каждой машине, на которой вы работаете. Это гарантирует, что вы будете работать в одной среде, где бы вы ни находились.
10. Есть несколько способов достижения цели.
Когда я начинал писать код, я думал, что логика в коде очень строгая и должна следовать определённому шаблону. На самом деле единственным ограничителем является синтаксис используемого языка.
11. Воспринимайте ошибки как уроки.
Если вы посмотрите любую историю успеха, вы обнаружите, что на самом деле она состоит из попыток, ошибок и новых попыток чуть менее, чем полностью. Настойчивость и любопытство – ключи к победе.
12. Важно найти свою нишу.
Блуждание от технологии к технологии ни к чему не приведёт. Определитесь со своими интересами и исследуйте доступные области, прежде чем углубляться в одну из них.
13. Интересуйтесь, почему всё работает.
Всегда пытайтесь открыть для себя то, что скрывается под капотом. Недостаточно видеть, как вещи каким-то волшебным образом работают.
14. Увлечение сторонними проектами полезно.
Когда дело доходит до сторонних проектов, выберите то, что вам действительно интересно. Это повысит вашу мотивацию, поскольку вы будете заботиться о конечном результате.
15. Это марафон, а не спринт.
Область разработки постоянно развивается, поэтому приготовьтесь к непрерывному обучению. Если начать слишком активно, вы быстро устанете.
Продолжение следует…
Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka
День девятьсот пятьдесят восьмой. #Оффтоп
Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру. Продолжение
Начало 1-15
16. Не изобретайте велосипед.
Прежде чем приступить к проекту, посмотрите, что другие разработчики использовали для решения подобных проблем. Уже должно быть решение практически для всего, вопрос лишь в том, насколько вы хороши в поисках.
17. Легко увлечься.
Быть активным в сообществе - это здорово, но имейте в виду, что там вы часто открываете новые более оптимизированные технологии, более современные API и фреймворки и т.п. Это не всегда означает, что ваш текущий стек плохой, и вам следует его менять.
18. Пособия часто вводят вас в заблуждение.
Примеры в пособиях в основном уже предварительно написаны, протестированы и переработаны. Вы можете подумать, что ни на что не годны, потому что не можете придумать такое же быстрое и эффективное решение с первого раза. Имейте в виду, что создатели примеров тоже пришли к этому решению не сразу.
19. Уроки не сделают вас профессионалом.
Просмотр курса или чтение учебника может быть полезным для ознакомления с технологиями, но они не помогут вам самостоятельно писать код. Попробуйте читать документацию, и чаще практиковаться, чтобы развить аналитическое мышление и находить свои собственные решения.
20. Никакая технология не идеальна.
У каждой технологии есть свои преимущества и недостатки. Если сомневаетесь, исследуйте и сравните альтернативы: как они работают, как решают конкретные задачи, - и выберите ту, что вам по душе.
21. Ваша способность обучаться имеет значение.
Когда вы попадаете на работу в компанию, скорее всего, вы не будете знакомы с их технологическим стеком. Важно не то, сколько технологий вы знаете, а то, насколько быстро вы сможете освоить конкретную незнакомую вам технологию.
22. Контроль версий - необходимость.
Клиенты часто просят вернуться к предыдущему дизайну и не могут определиться с конкретными особенностями реализации. Контроль версий придёт вам на помощь, а также обеспечит постоянное резервное копирование вашего кода.
23. Ошибки могут быть действительно пугающими.
Будьте готовы к серьезным ошибкам, на исправление которых могут потребоваться часы или даже дни. Вы будете напуганы низким уровнем продуктивности в это время, но это пройдёт, как только исправите ошибку.
24. Знайте, чему не учиться.
Сегодня в океане технологий легко запутаться. По иронии судьбы, сегодня один из лучших навыков - научиться понимать, что не стоит изучать.
25. Чтение кода делает вас лучше.
Когда вы пишете код, вы используете то, что знаете. Важно читать код других разработчиков, изучать различные паттерны проектирования и лучшие практики.
26. Будьте скромным, и другие будут уважать вас.
Празднуйте свои достижения внутри, но скромнее выражайте эмоции. Хвастовство до добра не доведёт.
27. Перфекционизм замедлит вас.
Предпочитать качество количеству - это здорово. Но не переусердствуйте, иначе у вас останутся сотни незавершённых проектов.
28. Открытый исходный код - это здорово.
Открытый исходный код в последнее время распространился от мелких частных репозиториев до крупных компаний. Даже код .NET теперь открыт. Убедитесь, что вы изучаете передовой опыт и паттерны проектирования, используемые другими людьми.
29. Диплом не обязателен.
Клиентов больше волнуют не корочки, а ваше практическое умение решать их проблемы.
30. Разбейте проблему, когда застрянете.
Часто решение проблемы может показаться трудным, поскольку проблема слишком обширна. Разбейте её на части и решайте каждую часть по отдельности.
31. Корпорациям вы нужны для CRUD-приложений.
Сердце корпоративных приложений - это CRUD-операции. Учитесь и будьте готовы работать с ними ежедневно, если планируете там работать.
32. Проект никогда не бывает полностью завершён.
Всегда найдутся способы улучшить и оптимизировать каждый проект. Рассматривайте окончание как момент, когда проект соответствует требованиям и достаточно хорош для отправки клиенту.
Продолжение следует…
Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka
Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру. Продолжение
Начало 1-15
16. Не изобретайте велосипед.
Прежде чем приступить к проекту, посмотрите, что другие разработчики использовали для решения подобных проблем. Уже должно быть решение практически для всего, вопрос лишь в том, насколько вы хороши в поисках.
17. Легко увлечься.
Быть активным в сообществе - это здорово, но имейте в виду, что там вы часто открываете новые более оптимизированные технологии, более современные API и фреймворки и т.п. Это не всегда означает, что ваш текущий стек плохой, и вам следует его менять.
18. Пособия часто вводят вас в заблуждение.
Примеры в пособиях в основном уже предварительно написаны, протестированы и переработаны. Вы можете подумать, что ни на что не годны, потому что не можете придумать такое же быстрое и эффективное решение с первого раза. Имейте в виду, что создатели примеров тоже пришли к этому решению не сразу.
19. Уроки не сделают вас профессионалом.
Просмотр курса или чтение учебника может быть полезным для ознакомления с технологиями, но они не помогут вам самостоятельно писать код. Попробуйте читать документацию, и чаще практиковаться, чтобы развить аналитическое мышление и находить свои собственные решения.
20. Никакая технология не идеальна.
У каждой технологии есть свои преимущества и недостатки. Если сомневаетесь, исследуйте и сравните альтернативы: как они работают, как решают конкретные задачи, - и выберите ту, что вам по душе.
21. Ваша способность обучаться имеет значение.
Когда вы попадаете на работу в компанию, скорее всего, вы не будете знакомы с их технологическим стеком. Важно не то, сколько технологий вы знаете, а то, насколько быстро вы сможете освоить конкретную незнакомую вам технологию.
22. Контроль версий - необходимость.
Клиенты часто просят вернуться к предыдущему дизайну и не могут определиться с конкретными особенностями реализации. Контроль версий придёт вам на помощь, а также обеспечит постоянное резервное копирование вашего кода.
23. Ошибки могут быть действительно пугающими.
Будьте готовы к серьезным ошибкам, на исправление которых могут потребоваться часы или даже дни. Вы будете напуганы низким уровнем продуктивности в это время, но это пройдёт, как только исправите ошибку.
24. Знайте, чему не учиться.
Сегодня в океане технологий легко запутаться. По иронии судьбы, сегодня один из лучших навыков - научиться понимать, что не стоит изучать.
25. Чтение кода делает вас лучше.
Когда вы пишете код, вы используете то, что знаете. Важно читать код других разработчиков, изучать различные паттерны проектирования и лучшие практики.
26. Будьте скромным, и другие будут уважать вас.
Празднуйте свои достижения внутри, но скромнее выражайте эмоции. Хвастовство до добра не доведёт.
27. Перфекционизм замедлит вас.
Предпочитать качество количеству - это здорово. Но не переусердствуйте, иначе у вас останутся сотни незавершённых проектов.
28. Открытый исходный код - это здорово.
Открытый исходный код в последнее время распространился от мелких частных репозиториев до крупных компаний. Даже код .NET теперь открыт. Убедитесь, что вы изучаете передовой опыт и паттерны проектирования, используемые другими людьми.
29. Диплом не обязателен.
Клиентов больше волнуют не корочки, а ваше практическое умение решать их проблемы.
30. Разбейте проблему, когда застрянете.
Часто решение проблемы может показаться трудным, поскольку проблема слишком обширна. Разбейте её на части и решайте каждую часть по отдельности.
31. Корпорациям вы нужны для CRUD-приложений.
Сердце корпоративных приложений - это CRUD-операции. Учитесь и будьте готовы работать с ними ежедневно, если планируете там работать.
32. Проект никогда не бывает полностью завершён.
Всегда найдутся способы улучшить и оптимизировать каждый проект. Рассматривайте окончание как момент, когда проект соответствует требованиям и достаточно хорош для отправки клиенту.
Продолжение следует…
Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka
День девятьсот пятьдесят девятый. #Оффтоп
Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру.
Начало 1-15
Продолжение 16-32
33. Хороший код легко читать и поддерживать.
Независимо от того, работаете ли вы один или в команде, всегда старайтесь писать код, так как будто с ним будет работать кто-то другой. В сложных частях оставляйте комментарии, поясняющие принцип работы.
34. Первый язык всегда самый трудный.
Я видел, как люди часто спрашивали, какой язык сложнее всего выучить. На самом деле сложность изучения зависит от количества опыта.
35. Google и Stack Overflow – ваши друзья.
Эти ресурсы созданы для того, чтобы вам могли помочь. Не стесняйтесь гуглить или заглядывать в SO, даже если кто-то смотрит. Они тоже это делают.
36. Коммуникативные навыки недооценены.
Один только код не всегда определяет ваш успех. Важно практиковать взаимодействие с людьми. Знание всех передовых технологий не имеет смысла, если вы не умеете их продать. Вы должны быть нужны вашим клиентам, а не наоборот.
37. Всегда помните о правиле 20/80.
Имейте в виду, что последние 20% проекта занимают 80% времени. Так что дважды подумайте, прежде чем сообщать клиенту о прогрессе.
38. Фреймворки приходят и уходят.
В 10 раз ценнее изучить технологию, на которой они основаны, чтобы вы были готовы выбрать конкретный фреймворк, когда возникнет необходимость.
39. Хорошо знать что-то отлично, чем притворяться, что знаешь всё понемногу.
Вместо того, чтобы пытаться освоить всё, проведите небольшое исследование в интересующей вас области, изучите доступные стеки, выберите один и изучите его досконально. Попытка стать мастером на все руки в итоге не сделает вас мастером ни в чём.
40. Для тестирования есть причина.
Заведите себе хорошую привычку писать тесты. Несмотря на то, что поначалу вам может показаться, что вы выполняете ненужную работу, они помогут вам сэкономить много времени, особенно в больших проектах.
41. Достижения лучше всего повышают вашу мотивацию.
Цените моменты, когда вы учитесь, и когда, наконец, у вас начинает что-то получаться. Так люди получают удовольствие от работы и чувствуют себя ценными. Относитесь к ним как к топливу для вашей мотивации.
42. Не берите больше, чем можете унести.
Найдите тонкую грань между выбором проблемы достаточно сложной, чтобы изучить что-то новое, но также достаточно узкой, чтобы её можно было решить.
43. Не сравнивайте себя с другими.
Легко разочароваться, если сравнивать себя с достижениями других разработчиков. Вы учитесь в своём собственном темпе, и это прекрасно.
44. Не принимайте критику на свой счёт.
Конструктивная критика - это ценная обратная связь, в которой указываются ошибки или улучшения, которых вы сами не заметили. В итоге это приводит к более качественному продукту.
45. Все писали плохой код.
Не стыдитесь смотреть на код, который вы написали несколько лет назад. Может показаться, что это писали не вы или вы были в бреду, и вам может быть стыдно за такой код. Помните, что на самом деле это явный признак того, что вы прогрессируете.
Окончание следует…
Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka
Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру.
Начало 1-15
Продолжение 16-32
33. Хороший код легко читать и поддерживать.
Независимо от того, работаете ли вы один или в команде, всегда старайтесь писать код, так как будто с ним будет работать кто-то другой. В сложных частях оставляйте комментарии, поясняющие принцип работы.
34. Первый язык всегда самый трудный.
Я видел, как люди часто спрашивали, какой язык сложнее всего выучить. На самом деле сложность изучения зависит от количества опыта.
35. Google и Stack Overflow – ваши друзья.
Эти ресурсы созданы для того, чтобы вам могли помочь. Не стесняйтесь гуглить или заглядывать в SO, даже если кто-то смотрит. Они тоже это делают.
36. Коммуникативные навыки недооценены.
Один только код не всегда определяет ваш успех. Важно практиковать взаимодействие с людьми. Знание всех передовых технологий не имеет смысла, если вы не умеете их продать. Вы должны быть нужны вашим клиентам, а не наоборот.
37. Всегда помните о правиле 20/80.
Имейте в виду, что последние 20% проекта занимают 80% времени. Так что дважды подумайте, прежде чем сообщать клиенту о прогрессе.
38. Фреймворки приходят и уходят.
В 10 раз ценнее изучить технологию, на которой они основаны, чтобы вы были готовы выбрать конкретный фреймворк, когда возникнет необходимость.
39. Хорошо знать что-то отлично, чем притворяться, что знаешь всё понемногу.
Вместо того, чтобы пытаться освоить всё, проведите небольшое исследование в интересующей вас области, изучите доступные стеки, выберите один и изучите его досконально. Попытка стать мастером на все руки в итоге не сделает вас мастером ни в чём.
40. Для тестирования есть причина.
Заведите себе хорошую привычку писать тесты. Несмотря на то, что поначалу вам может показаться, что вы выполняете ненужную работу, они помогут вам сэкономить много времени, особенно в больших проектах.
41. Достижения лучше всего повышают вашу мотивацию.
Цените моменты, когда вы учитесь, и когда, наконец, у вас начинает что-то получаться. Так люди получают удовольствие от работы и чувствуют себя ценными. Относитесь к ним как к топливу для вашей мотивации.
42. Не берите больше, чем можете унести.
Найдите тонкую грань между выбором проблемы достаточно сложной, чтобы изучить что-то новое, но также достаточно узкой, чтобы её можно было решить.
43. Не сравнивайте себя с другими.
Легко разочароваться, если сравнивать себя с достижениями других разработчиков. Вы учитесь в своём собственном темпе, и это прекрасно.
44. Не принимайте критику на свой счёт.
Конструктивная критика - это ценная обратная связь, в которой указываются ошибки или улучшения, которых вы сами не заметили. В итоге это приводит к более качественному продукту.
45. Все писали плохой код.
Не стыдитесь смотреть на код, который вы написали несколько лет назад. Может показаться, что это писали не вы или вы были в бреду, и вам может быть стыдно за такой код. Помните, что на самом деле это явный признак того, что вы прогрессируете.
Окончание следует…
Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka
День девятьсот шестидесятый. #Оффтоп
Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру. Окончание
Начало 1-15
Продолжение 16-32
Продолжение 33-45
46. Один законченный проект лучше 10 незавершённых.
Старайтесь работать над одним или парой проектов одновременно и следовать графику исполнения работы. Помните, что важны только готовые проекты.
47. Лучший способ учиться - обучать других.
Чтобы научить других, вы должны сами хорошо изучить тему. Это гарантирует, что вы познакомитесь с концепцией досконально, и будет беспроигрышным вариантом, если вы поделитесь своими знаниями.
48. Вы никогда не будете полностью готовы устроиться на работу.
Обучение программированию - это путь, а не цель, поэтому вы всегда будете чувствовать себя где-то в середине пути для достижения чего-либо. Не позволяйте этому вводить вас в заблуждение и откликайтесь на вакансию в любом случае.
49. Не увлекайтесь хайповыми темами.
Будьте в курсе трендов, но используйте новинки, только если понимаете основные принципы работы и варианты использования. Таким образом, вы будете знать, какие проблемы инструмент решает лучше всего, и выберете его только тогда, когда в нём возникнет необходимость.
50. Сосредоточьтесь на оглавлении, а не на содержании.
В настоящее время важно быстро находить информацию. Если вы знаете, что вам нужно и где это искать, то найти нужную вещь - лишь вопрос времени.
51. Будьте губкой для знаний.
Выработайте привычку учиться каждый день, чтобы оставаться конкурентоспособным. Обратите внимание на источники информации. Качество важнее количества.
52. Научитесь говорить «нет».
Если вы никогда не отказываетесь ни от чего, другие рано или поздно начнут пользоваться этим, и вы в итоге будете работать больше, чем нужно.
53. Распланируйте неделю и расставьте приоритеты.
Постарайтесь выделить время, чтобы спланировать всё заранее. Таким образом будет легче определить задачи, над которыми вы работаете, и порядок их выполнения.
54. Перерывы, творят чудеса.
Если вы застряли, попробуйте какое-то время не делать ничего, связанного с программированием. Проведите время с семьей, займитесь хобби или сходите на прогулку. Часто после паузы вы легко будете находить решение.
55. Спорт и полноценный сон повышают продуктивность.
Когда дело доходит до продуктивности, вы часто будете достигать большего, если будете спать 8 часов, а работать 4 часа, чем наоборот. Совместите это с регулярными физическими упражнениями для пущего эффекта.
56. Не технология, а ваше воображение - единственное, что вас ограничивает.
Большинство языков/фреймворков и т.д. могут делать всё то же, что предлагают их альтернативы. Но иногда бывает, что вас поражает, как альтернативная технология изящно решает проблему. На самом деле ваша технология скорее всего может решить эту проблему не менее изящно и эффективно. Вас ограничивает только ваше воображение.
Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka
Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру. Окончание
Начало 1-15
Продолжение 16-32
Продолжение 33-45
46. Один законченный проект лучше 10 незавершённых.
Старайтесь работать над одним или парой проектов одновременно и следовать графику исполнения работы. Помните, что важны только готовые проекты.
47. Лучший способ учиться - обучать других.
Чтобы научить других, вы должны сами хорошо изучить тему. Это гарантирует, что вы познакомитесь с концепцией досконально, и будет беспроигрышным вариантом, если вы поделитесь своими знаниями.
48. Вы никогда не будете полностью готовы устроиться на работу.
Обучение программированию - это путь, а не цель, поэтому вы всегда будете чувствовать себя где-то в середине пути для достижения чего-либо. Не позволяйте этому вводить вас в заблуждение и откликайтесь на вакансию в любом случае.
49. Не увлекайтесь хайповыми темами.
Будьте в курсе трендов, но используйте новинки, только если понимаете основные принципы работы и варианты использования. Таким образом, вы будете знать, какие проблемы инструмент решает лучше всего, и выберете его только тогда, когда в нём возникнет необходимость.
50. Сосредоточьтесь на оглавлении, а не на содержании.
В настоящее время важно быстро находить информацию. Если вы знаете, что вам нужно и где это искать, то найти нужную вещь - лишь вопрос времени.
51. Будьте губкой для знаний.
Выработайте привычку учиться каждый день, чтобы оставаться конкурентоспособным. Обратите внимание на источники информации. Качество важнее количества.
52. Научитесь говорить «нет».
Если вы никогда не отказываетесь ни от чего, другие рано или поздно начнут пользоваться этим, и вы в итоге будете работать больше, чем нужно.
53. Распланируйте неделю и расставьте приоритеты.
Постарайтесь выделить время, чтобы спланировать всё заранее. Таким образом будет легче определить задачи, над которыми вы работаете, и порядок их выполнения.
54. Перерывы, творят чудеса.
Если вы застряли, попробуйте какое-то время не делать ничего, связанного с программированием. Проведите время с семьей, займитесь хобби или сходите на прогулку. Часто после паузы вы легко будете находить решение.
55. Спорт и полноценный сон повышают продуктивность.
Когда дело доходит до продуктивности, вы часто будете достигать большего, если будете спать 8 часов, а работать 4 часа, чем наоборот. Совместите это с регулярными физическими упражнениями для пущего эффекта.
56. Не технология, а ваше воображение - единственное, что вас ограничивает.
Большинство языков/фреймворков и т.д. могут делать всё то же, что предлагают их альтернативы. Но иногда бывает, что вас поражает, как альтернативная технология изящно решает проблему. На самом деле ваша технология скорее всего может решить эту проблему не менее изящно и эффективно. Вас ограничивает только ваше воображение.
Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka
День девятьсот шестьдесят первый. #ЗаметкиНаПолях
Как Добавить Представление в EF Core DbContext
Представление (View) - это виртуальная таблица, основанная на результатах предопределённого запроса. Представления позволяют инкапсулировать сложный запрос в логический объект в базе данных.
Допустим, у нас есть две таблицы: продуктов (
Теперь мы можем использовать наше новое представление так же, как любой другой
Источник: https://khalidabuhakmeh.com/how-to-add-a-view-to-an-entity-framework-core-dbcontext
Как Добавить Представление в EF Core DbContext
Представление (View) - это виртуальная таблица, основанная на результатах предопределённого запроса. Представления позволяют инкапсулировать сложный запрос в логический объект в базе данных.
Допустим, у нас есть две таблицы: продуктов (
Products) и оценок продуктов (Ratings). Наша цель - создать представление SQL, которое может упростить следующий оператор LINQ:var prodRatings =Сначала нужно создать пустую миграцию, чтобы добавить определение представления:
db.Products
.Select(x => new {
id = x.Id,
name = x.Name,
avg = x.Ratings.Average(r => r.Stars)
});
dotnet ef migrations add ProductRatingAvgЗатем откроем файл новой миграции в папке
Migrations. Он содержит два метода, в которые добавляется код, выполняемый при применении (Up) и откате (Down) миграции. Мы можем вручную добавить любой код, который хотим выполнить. Например, для создания представления добавим выполнение произвольного Sql запроса:public partial class ProductRatingAvg : MigrationСледующий шаг – добавить модель
{
protected override void
Up(MigrationBuilder mb)
{
mb.Sql(@"
create view ProductAverages as
select p.Id, p.Name, avg(r.Stars) as AverageRating
from Products p inner join Ratings r on p.Id = R.ProductionId
group by p.Id, p.Name;");
}
protected override void
Down(MigrationBuilder mb)
{
mb.Sql(@"drop view ProductAverages;");
}
}
ProductAverage в DbContext:public class ProductAverage {
public int Id { get; set; }
public string Name { get; set; }
public double AverageRating { get; set; }
}
public DbSet<ProductAverage> ProductAverages { get; set; }
Далее привяжем сущность к представлению в методе DbContext.OnModelCreating:modelBuilderНаше свойство
.Entity<ProductAverage>()
.ToView(nameof(ProductAverages))
.HasKey(t => t.Id);
ProductAverages называется так же, как представление, поэтому мы можем использовать nameof, хотя в метод ToView() можно передать любую строку.Теперь мы можем использовать наше новое представление так же, как любой другой
DbSet:var db = new MyDbContext();Помните, что эта коллекция является представлением, и любая попытка обновить данные потерпит неудачу. Некоторые базы данных поддерживают обновления представлений, но только если мы определяем представление на основе одной таблицы.
…
var averages =
await db.ProductAverages.ToListAsync();
Источник: https://khalidabuhakmeh.com/how-to-add-a-view-to-an-entity-framework-core-dbcontext
День девятьсот шестьдесят второй. #NuGet
Генерация Фейковых Данных с Помощью Faker.Net
При разработке, тестировании или демонстрации продукта часто важно использовать данные, которые не являются настоящими. Либо потому, что у вас ещё нет фактических данных, либо потому, что вы не хотите показывать или выбирать данные реальных пользователей, которые могут содержать конфиденциальную информацию. Faker.Net поможет в этом, упростив получение множества случайных имен, адресов, email адресов, и прочей личной информации.
Пакет .NET изначально был портом библиотеки Ruby от 2009 года, но во многом разошлась с ней. Библиотека Ruby сама по себе была портом библиотеки Perl Data::Faker от 2007 года. .NET библиотека продолжает использоваться и постоянно обновляется. Причина её популярности, вероятно, связана со множеством вариантов использования и очень простой структурой.
Сначала нужно установить пакет Faker.Net. Мы можем сделать это через диспетчер пакетов в Visual Studio или через интерфейс CLI:
Мы можем сгенерировать имя из комбинации предопределённых имени, фамилии и отчества, либо сразу полное имя с обращением:
Последний шаг – текст для биографии. Можно просто взять несколько предложений из «рыбы» "Lorem Ipsum…":
- доменные имена:
Источник: https://blog.elmah.io/easy-generation-of-fake-dummy-data-in-c-with-faker-net/
Генерация Фейковых Данных с Помощью Faker.Net
При разработке, тестировании или демонстрации продукта часто важно использовать данные, которые не являются настоящими. Либо потому, что у вас ещё нет фактических данных, либо потому, что вы не хотите показывать или выбирать данные реальных пользователей, которые могут содержать конфиденциальную информацию. Faker.Net поможет в этом, упростив получение множества случайных имен, адресов, email адресов, и прочей личной информации.
Пакет .NET изначально был портом библиотеки Ruby от 2009 года, но во многом разошлась с ней. Библиотека Ruby сама по себе была портом библиотеки Perl Data::Faker от 2007 года. .NET библиотека продолжает использоваться и постоянно обновляется. Причина её популярности, вероятно, связана со множеством вариантов использования и очень простой структурой.
Сначала нужно установить пакет Faker.Net. Мы можем сделать это через диспетчер пакетов в Visual Studio или через интерфейс CLI:
dotnet add package Faker.NetТеперь сгенерируем данные. Допустим, нам нужно создать несколько экземпляров этой модели:
class UserProfileЗдесь нам нужно сгенерировать имя, какое-то случайное число из нужного диапазона, адрес и некоторый случайный текст для биографии.
{
string Name { get; set; }
int Followers { get; set; }
string Address { get; set; }
string Bio { get; set; }
}
Мы можем сгенерировать имя из комбинации предопределённых имени, фамилии и отчества, либо сразу полное имя с обращением:
var user = new UserProfile();Для генерации случайных чисел Faker.Net использует класс
user.Name = Faker.Name.FullName(NameFormats.WithPrefix);
// "Mrs. Jerod Nader"
RandomNumberGenerator из System.Security.Cryptography:user.Followers = Faker.RandomNumber.Next(0, 10000);Далее создадим адрес:
// 3452
user.Address = $"{Faker.Address.Country()}, {Faker.Address.City()}";
// "Fiji, Wavaland"
Заметьте, что страна и город создаются независимо, поэтому они не пройдут валидацию, если она у вас есть. Также можно создавать индексы, названия улиц и т.п.Последний шаг – текст для биографии. Можно просто взять несколько предложений из «рыбы» "Lorem Ipsum…":
user.Bio = String.Join(" ", Faker.Lorem.Sentences(3));
// "Ea voluptas maiores nihil quia et eum. Vel et eos est architecto rerum est. Eum esse voluptatem ab necessitatibus."
Кроме того, можно создавать:- доменные имена:
user.CompanyDomain = Faker.Internet.DomainName();- email адреса (заметьте, что использовано имя пользователя):
// "torp.com"
user.Email = Faker.Internet.Email(user.Name);- URL адреса:
// "[email protected]"
user.resources = Enumerable.Range(0,2).Select(_ => Faker.Internet.SecureUrl());- и многое другое.
// "https://www.quigleyrobel.us/films/page.aspx"
// "https://www.braunborer.uk/guide/page.jsp"
Источник: https://blog.elmah.io/easy-generation-of-fake-dummy-data-in-c-with-faker-net/
День девятьсот шестьдесят третий. #Оффтоп
Сегодня порекомендую вам лёгкое, немного философское видео, которое попалось мне на просторах ютуба. Том Скотт сделал так, чтобы название видео содержало актуальное число его просмотров. Прошло уже полтора года, и, как видно из моего скриншота, код до сих пор работает. Однако никто не знает, когда он прекратит работать. Ведь наши приложения больше не существуют сами по себе. Они зачастую зависят от множества сторонних API и сервисов, которые в определённый момент могут перестать работать и сломать наши приложения. Ничего уже не делается на века. Но это вовсе не значит, что не надо ничего делать.
https://www.youtube.com/watch?v=BxV14h0kFs0
Сегодня порекомендую вам лёгкое, немного философское видео, которое попалось мне на просторах ютуба. Том Скотт сделал так, чтобы название видео содержало актуальное число его просмотров. Прошло уже полтора года, и, как видно из моего скриншота, код до сих пор работает. Однако никто не знает, когда он прекратит работать. Ведь наши приложения больше не существуют сами по себе. Они зачастую зависят от множества сторонних API и сервисов, которые в определённый момент могут перестать работать и сломать наши приложения. Ничего уже не делается на века. Но это вовсе не значит, что не надо ничего делать.
https://www.youtube.com/watch?v=BxV14h0kFs0
День девятьсот шестьдесят четвёртый. #TipsAndTricks
Уменьшаем Длину GUID в URL и Json
GUID обычно используются в качестве ключа в базе данных. Если вы хотите создать URL-адрес для определённой записи, вы можете использовать GUID в нём. Но как отобразить GUID в URL-адресе? Есть несколько вариантов:
1.
3.
4.
Вот пример кода для добавления кодирования и декодирования GUID в качестве безопасной строки URL-адреса base64:
Чтобы легко использовать короткие идентификаторы GUID в приложении ASP.NET Core, вы можете создать структуру для обёртывания идентификатора GUID:
Источник: https://www.meziantou.net/reducing-the-string-length-of-guids-in-urls.htm
Уменьшаем Длину GUID в URL и Json
GUID обычно используются в качестве ключа в базе данных. Если вы хотите создать URL-адрес для определённой записи, вы можете использовать GUID в нём. Но как отобразить GUID в URL-адресе? Есть несколько вариантов:
1.
Guid.ToString() – 36 символов00000000-0000-0000-0000-0000000000002.
Guid.ToString("N") – 3200000000000000000000000000000000Уберёт лишние символы, но всё равно результат довольно длинный.
3.
Convert.ToBase64String – 240000000000000000000000==Кодировка base64 небезопасна для URL-адресов, поскольку может содержать символ
/. Это означает, что вам нужно закодировать значение с помощью Uri.EscapeDataString. Кроме того, в конце строки есть символы-заполнители.4.
WebEncoders.Base64UrlEncode - 220000000000000000000000Этот метод преобразует массив байтов в строку base64, которую можно безопасно использовать в URL-адресе.
Вот пример кода для добавления кодирования и декодирования GUID в качестве безопасной строки URL-адреса base64:
using Microsoft.AspNetCore.WebUtilities;Привязка модели ASP.NET Core
…
string EncodeGuid(Guid guid)
{
Span<byte> bytes = stackalloc byte[16];
guid.TryWriteBytes(bytes);
return WebEncoders.Base64UrlEncode(bytes);
}
…
Guid DecodeGuid(string guid) =>
return new Guid(WebEncoders.Base64UrlDecode(str));
Чтобы легко использовать короткие идентификаторы GUID в приложении ASP.NET Core, вы можете создать структуру для обёртывания идентификатора GUID:
public readonly struct ShortGuidТакже потребуется определить конвертеры, которые будут использоваться связывателем модели ASP.NET Core и сериализатором JSON. Полный код структуры в источнике по ссылке ниже.
{
private readonly Guid _value;
public ShortGuid(Guid value) =>
_value = value;
public static implicit operator
Guid(ShortGuid sGuid) => sGuid._value;
public static implicit operator
ShortGuid(Guid guid) => new(guid);
public static ShortGuid Parse(string input) =>
new Guid(WebEncoders.Base64UrlDecode(input));
public override string ToString()
{
Span<byte> bytes = stackalloc byte[16];
_value.TryWriteBytes(bytes);
return WebEncoders.Base64UrlEncode(bytes);
}
}
Источник: https://www.meziantou.net/reducing-the-string-length-of-guids-in-urls.htm
День девятьсот шестьдесят пятый. #ЧтоНовенького
Быстрые Действия для Типичных Задач с Помощью IntelliCode
IntelliCode теперь может определять, типичные паттерны в коде и рекомендовать правильное быстрое действие прямо во время набора текста. На данный момент IntelliCode может обнаруживать и предлагать быстрое действие для создания конструктора и добавления параметра в конструктор. Но сценарии будут расширены в будущих версиях. В Visual Studio 2022 Preview 4 эти новые возможности предложений IntelliCode включены по умолчанию.
Раньше такие подсказки показывались в виде лампочки слева от строки. Теперь, пока вы печатаете, IntelliCode проверяет изменения в коде и, используя технологию PROSE, сопоставляет их с распространёнными паттернами и предлагает варианты завершения.
Источник: https://devblogs.microsoft.com/visualstudio/discover-quick-action-intellicode/
Быстрые Действия для Типичных Задач с Помощью IntelliCode
IntelliCode теперь может определять, типичные паттерны в коде и рекомендовать правильное быстрое действие прямо во время набора текста. На данный момент IntelliCode может обнаруживать и предлагать быстрое действие для создания конструктора и добавления параметра в конструктор. Но сценарии будут расширены в будущих версиях. В Visual Studio 2022 Preview 4 эти новые возможности предложений IntelliCode включены по умолчанию.
Раньше такие подсказки показывались в виде лампочки слева от строки. Теперь, пока вы печатаете, IntelliCode проверяет изменения в коде и, используя технологию PROSE, сопоставляет их с распространёнными паттернами и предлагает варианты завершения.
Источник: https://devblogs.microsoft.com/visualstudio/discover-quick-action-intellicode/
День девятьсот шестьдесят шестой. #TypesAndLanguages
Ключевые различия между C# и F#. Начало
И C#, и F# по-своему уникальны. В чём их различия и что сделать проще в C#, а что в F#?
В чём C# превосходит F#?
1. Асинхронность
Асинхронный код в C# выполняется быстрее, чем в F#. Это в первую очередь потому, что асинхронные конструкции изначально поддерживаются компилятором и генерируют оптимизированный код. Как только в F# появится аналогичная поддержка, эта разница уменьшится. Кроме того, она не очень важна для типичного бизнес-приложения. Мы можем написать библиотеку C# и вызвать ее из F# для реального кода, чувствительного к производительности.
2. Взаимодействие с библиотеками .NET
Поскольку большинство библиотек .NET написано на C#, разработчику проще работать с ними на C# по сравнению с F#.
3. Ранний возврат
В C# для возвращения из метода используется ключевое слово return. Это невозможно в F#. В глубоко вложенных блоках кода эта функция действительно полезна.
4. Ко-/контравариантность
Вариантность поддерживается в C#, но на данный момент не поддерживается в F#. Это особенно полезно для библиотечного кода, который имеет дело с обобщениями.
5. ООП в общем
В C# работать с защищёнными классами проще, так как в нём есть ключевое слово protected, которого нет в F#. Кроме того, реализация типов внутренних классов, неявных интерфейсов и частичных классов возможна в C#, но не в F#.
6. Неявное приведение
Неявное приведение типов поддерживается в C#, но не поддерживается в F#. В F# не поддерживается ни неявный апкаст, ни неявный даункаст. Следовательно, в C# проще использовать библиотеки, полагающиеся на неявное приведение типов.
7. Генераторы кода
Генераторы исходного кода недоступны для F#. Хотя есть Myriad.
8. Упорядочивание файлов
В C# упорядочивание файлов и пространств имён возможно любым способом. В F# строгий порядок (снизу вверх).
9. Инструменты и поддержка в IDE
Инструменты и поддержка IDE в C# лучше по сравнению с F#.
10. Отладка
Во всех IDE процесс отладки проще в C#, чем в F#. Асинхронные рабочие процессы особенно сложно отлаживать на F#.
11. Низкоуровневый код
Небезопасный код и Invoke/P, span и закреплённые указатели также поддерживаются только в C#.
12. WinForms и WPF
C# начинался с разработки клиентов WPF или Winform. Это не важная область для F#.
13. Entity Framework
В мире .NET Entity Framework - очень популярен. Разработчикам инстинктивно приходит в голову не использовать его в F#, потому что его дизайн противоречит F#.
14. Асинхронный Main
В методе Main async может использоваться в C#, в то время как для F# в нём используется Async.RunSynchronously.
Окончание следует…
Источник: https://www.partech.nl/nl/publicaties/2021/06/key-differences-between-c-sharp-and-f-sharp
UPD: поскольку я не спец в F#, оказалось, что некоторые пункты из поста не совсем верны. Спасибо @Lanayx за комментарий
Ключевые различия между C# и F#. Начало
И C#, и F# по-своему уникальны. В чём их различия и что сделать проще в C#, а что в F#?
В чём C# превосходит F#?
1. Асинхронность
Асинхронный код в C# выполняется быстрее, чем в F#. Это в первую очередь потому, что асинхронные конструкции изначально поддерживаются компилятором и генерируют оптимизированный код. Как только в F# появится аналогичная поддержка, эта разница уменьшится. Кроме того, она не очень важна для типичного бизнес-приложения. Мы можем написать библиотеку C# и вызвать ее из F# для реального кода, чувствительного к производительности.
2. Взаимодействие с библиотеками .NET
Поскольку большинство библиотек .NET написано на C#, разработчику проще работать с ними на C# по сравнению с F#.
3. Ранний возврат
В C# для возвращения из метода используется ключевое слово return. Это невозможно в F#. В глубоко вложенных блоках кода эта функция действительно полезна.
4. Ко-/контравариантность
Вариантность поддерживается в C#, но на данный момент не поддерживается в F#. Это особенно полезно для библиотечного кода, который имеет дело с обобщениями.
5. ООП в общем
В C# работать с защищёнными классами проще, так как в нём есть ключевое слово protected, которого нет в F#. Кроме того, реализация типов внутренних классов, неявных интерфейсов и частичных классов возможна в C#, но не в F#.
6. Неявное приведение
Неявное приведение типов поддерживается в C#, но не поддерживается в F#. В F# не поддерживается ни неявный апкаст, ни неявный даункаст. Следовательно, в C# проще использовать библиотеки, полагающиеся на неявное приведение типов.
7. Генераторы кода
Генераторы исходного кода недоступны для F#. Хотя есть Myriad.
8. Упорядочивание файлов
В C# упорядочивание файлов и пространств имён возможно любым способом. В F# строгий порядок (снизу вверх).
9. Инструменты и поддержка в IDE
Инструменты и поддержка IDE в C# лучше по сравнению с F#.
10. Отладка
Во всех IDE процесс отладки проще в C#, чем в F#. Асинхронные рабочие процессы особенно сложно отлаживать на F#.
11. Низкоуровневый код
Небезопасный код и Invoke/P, span и закреплённые указатели также поддерживаются только в C#.
12. WinForms и WPF
C# начинался с разработки клиентов WPF или Winform. Это не важная область для F#.
13. Entity Framework
В мире .NET Entity Framework - очень популярен. Разработчикам инстинктивно приходит в голову не использовать его в F#, потому что его дизайн противоречит F#.
14. Асинхронный Main
В методе Main async может использоваться в C#, в то время как для F# в нём используется Async.RunSynchronously.
Окончание следует…
Источник: https://www.partech.nl/nl/publicaties/2021/06/key-differences-between-c-sharp-and-f-sharp
UPD: поскольку я не спец в F#, оказалось, что некоторые пункты из поста не совсем верны. Спасибо @Lanayx за комментарий
День девятьсот шестьдесят седьмой. #TypesAndLanguages
Ключевые различия между C# и F#. Окончание
Начало
В чём F# превосходит C#?
1. Неизменяемость по умолчанию
В F# всё неизменяемо, если вы не используете ключевое слово mutable. Неизменяемость помогает упростить распараллеливание и предотвратить дефекты.
2. Пайплайн
В F# пайплайн упрощает написание кода от верхнего левого угла до нижнего правого без использования каких-либо локальных переменных. Следовательно, облегчается чтение кода.
3. Всё - выражение
Понимание кода становятся проще при использовании выражений. Также упрощается отладка кода.
4. Вывод типа
Вывод типа в F# упрощает создание пользовательских типов. Рефакторинг также проще. Идея заключается в том, что нет необходимости указывать типы F# конструкций, за исключением случаев, когда компилятор не может вывести тип самостоятельно. В C# вывод типа также используется, но не так широко.
5. Разграниченные объединения (discriminated unions)
Разграниченные объединения обеспечивают поддержку значений, которые могут быть одним из нескольких именованных вариантов, возможно, каждое с разными значениями и типами. Они присутствуют в F#, что позволяет лучше моделировать бизнес-домен при использовании классов, записей, перечислений и интерфейсов. Лучшее моделирование приводит к простому коду и меньшему количеству дефектов.
6. Вычислительные выражения (computation expression)
Вычислительные выражения объединяют различные аспекты, такие как
7. Сопоставление по шаблону
Активные шаблоны в F# позволяют выделить часть шаблона, задать ей имя и использовать в других шаблонах, что упрощает чтение сложных шаблонов. Хотя C# в последнее время улучшил сопоставление по шаблону, но F# всё ещё впереди в этом.
8. Единицы измерения (Measure)
Использование единиц измерения подключает компилятор к проверке, что значения в арифметическом выражении имеют правильные единицы, что помогает предотвратить ошибки и делает код более выразительным.
9. Частичное применение (partial application) и композиция
Частичное применение широко используется в F#. Идея заключается в том, что, если вы фиксируете первые N параметров функции, вы получаете новую функцию для остальных параметров. Это помогает создавать дизайн на основе композиции функций.
Сравнение кода
C#:
У обоих языков есть свои преимущества и недостатки. Следовательно, важно выбрать язык в зависимости от создаваемого приложения, чтобы можно было использовать все преимущества их функций для написания хорошего кода. И что самое приятное, эти два языка прекрасно взаимодействуют друг с другом, что позволяет вам смешивать их и использовать в своём приложении.
Источник: https://www.partech.nl/nl/publicaties/2021/06/key-differences-between-c-sharp-and-f-sharp
Ключевые различия между C# и F#. Окончание
Начало
В чём F# превосходит C#?
1. Неизменяемость по умолчанию
В F# всё неизменяемо, если вы не используете ключевое слово mutable. Неизменяемость помогает упростить распараллеливание и предотвратить дефекты.
2. Пайплайн
В F# пайплайн упрощает написание кода от верхнего левого угла до нижнего правого без использования каких-либо локальных переменных. Следовательно, облегчается чтение кода.
3. Всё - выражение
Понимание кода становятся проще при использовании выражений. Также упрощается отладка кода.
4. Вывод типа
Вывод типа в F# упрощает создание пользовательских типов. Рефакторинг также проще. Идея заключается в том, что нет необходимости указывать типы F# конструкций, за исключением случаев, когда компилятор не может вывести тип самостоятельно. В C# вывод типа также используется, но не так широко.
5. Разграниченные объединения (discriminated unions)
Разграниченные объединения обеспечивают поддержку значений, которые могут быть одним из нескольких именованных вариантов, возможно, каждое с разными значениями и типами. Они присутствуют в F#, что позволяет лучше моделировать бизнес-домен при использовании классов, записей, перечислений и интерфейсов. Лучшее моделирование приводит к простому коду и меньшему количеству дефектов.
6. Вычислительные выражения (computation expression)
Вычислительные выражения объединяют различные аспекты, такие как
async, Option, Result, Validation и т.д. удобным для программиста способом. Это широко распространено в F#. Многие выражения представлены в библиотеке FsToolkit.7. Сопоставление по шаблону
Активные шаблоны в F# позволяют выделить часть шаблона, задать ей имя и использовать в других шаблонах, что упрощает чтение сложных шаблонов. Хотя C# в последнее время улучшил сопоставление по шаблону, но F# всё ещё впереди в этом.
8. Единицы измерения (Measure)
Использование единиц измерения подключает компилятор к проверке, что значения в арифметическом выражении имеют правильные единицы, что помогает предотвратить ошибки и делает код более выразительным.
9. Частичное применение (partial application) и композиция
Частичное применение широко используется в F#. Идея заключается в том, что, если вы фиксируете первые N параметров функции, вы получаете новую функцию для остальных параметров. Это помогает создавать дизайн на основе композиции функций.
Сравнение кода
C#:
public static class SumOfSquaresF#:
{
public static int Square(int i)
=> i * i;
// без LINQ
public static int Sum(int n)
{
int sum = 0;
for (int i=1; i<=n; i++)
sum += Square(i);
return sum;
}
// с LINQ
public static int SumLinq(int n)
=> Enumerable.Range(1, n).Select(Square).Sum();
}
…
var x = SumOfSquares.Sum(100);
let square x = x * x;Итого
let sumOfSquares n =
[1..n] |> List.map square |> List.sum
sumOfSquares 100
У обоих языков есть свои преимущества и недостатки. Следовательно, важно выбрать язык в зависимости от создаваемого приложения, чтобы можно было использовать все преимущества их функций для написания хорошего кода. И что самое приятное, эти два языка прекрасно взаимодействуют друг с другом, что позволяет вам смешивать их и использовать в своём приложении.
Источник: https://www.partech.nl/nl/publicaties/2021/06/key-differences-between-c-sharp-and-f-sharp
День девятьсот шестьдесят восьмой. #Оффтоп #Обучение
Как Быть Лучше Всех как Разработчик? Начало
Иногда мне кажется, что я бегу по рельсам, меня преследует скоростной поезд, на котором написано что-то вроде «новинки в технологиях». Я не могу остановиться и изменить направление, и у меня нет выбора, кроме как есть на бегу. В другие дни я смотрю на технологическую новинку, и она вся такая красивая и блестит на солнце. И тогда всё остальное теряет значение, даже приближающийся поезд. Я хочу эту блестяшку. Как же нам совладать с этими, казалось бы, противоположными потребностями?
Хватай блестяшку!
Мы все через это проходили. Мы смотрели на крутую новинку, которая обещала решить все наши проблемы. Мы хотели протянуть руку, схватить её и изучить. Остальное не важно. Конечно, для её изучения надо было выделить время. И если бы мы это сделали, мы (по крайней мере, в глазах некоторых людей) стали бы крутыми гуру. А другие бы подумали, что мы зря тратим время и ресурсы. Как обычно бывает в нашей отрасли, здесь следует найти компромисс. Давайте копнём глубже.
Технологии развиваются быстро, мы все это знаем. Как же нам оставаться впереди остальных, но не гнаться за каждой блестящей новинкой? Интересно, что погоня за каждой новинкой имеет негативный оттенок, а пребывание на острие технологий - позитивный. Я думаю, что эти вещи тесно связаны. Изучение новинок часто предвестник того, что вы в курсе текущих трендов. Конечно, если окажется, что новинка – это какой-нибудь Silverlight, вам нужно иметь возможность бросить её так же быстро, как вы за неё ухватились.
Схватить блестяшку и впоследствии знать о ней больше остальных - это может принести пользу нашей карьере. Конечно, если мы будем гоняться за каждой новинкой, мы можем обнаружить, что мало знаем о чём-либо вообще. Но давайте поговорим о том, что значит быть в курсе технологий.
Всё, что это на самом деле означает, - это делать что-то лучше, чем другие люди. Вам нужно быть впереди всех? Нуууу… «Это зависит». Многие успешные карьеры были построены без изучения новинок и без игры на опережение. Нам не обязательно знать новейшие и лучшие технологии, чтобы добиться успеха. Мы можем построить довольно успешную карьеру, специализируясь на устаревших технологиях. Если вам это в кайф, вперёд!
Однако многим из нас нравятся новые блестяшки, поэтому сосредоточимся на том, как вы можете опережать других в разработке.
Это наш путь обучения, такой, каким мы его определили. Это представление о том, что, если мы в курсе трендов, мы попадаем в верхний процент людей, которые знают о них. Именно сюда многие из нас стремятся, потому что:
- мы боимся остаться позади,
- мы боимся чего-то не знать,
- мы боимся быть наименее информированными людьми в компании, и т.п.
Наша потребность оставаться впереди всех, по крайней мере отчасти, вызвана страхами. Однако есть и другие движущие силы. Иногда мы стремимся быть впереди всех, потому что:
- мы хотим зарабатывать больше денег,
- мы хотим, чтобы нас считали успешными по каким-то показателям,
- мы получаем удовольствие от новейших технологий и получаем удовольствие от их изучения: «Ух, ты! Блестяшка!»
Всё это реальные опасения и реальные мотиваторы. У вас может быть ещё много других. Но как же выбрать стоящую новинку?
Окончание следует…
Источник: https://helenjoscott.iss.onedium.com/how-can-you-stay-ahead-of-the-curve-as-a-developer-a27d728980a2
Автор оригинала: Helen Scott
Как Быть Лучше Всех как Разработчик? Начало
Иногда мне кажется, что я бегу по рельсам, меня преследует скоростной поезд, на котором написано что-то вроде «новинки в технологиях». Я не могу остановиться и изменить направление, и у меня нет выбора, кроме как есть на бегу. В другие дни я смотрю на технологическую новинку, и она вся такая красивая и блестит на солнце. И тогда всё остальное теряет значение, даже приближающийся поезд. Я хочу эту блестяшку. Как же нам совладать с этими, казалось бы, противоположными потребностями?
Хватай блестяшку!
Мы все через это проходили. Мы смотрели на крутую новинку, которая обещала решить все наши проблемы. Мы хотели протянуть руку, схватить её и изучить. Остальное не важно. Конечно, для её изучения надо было выделить время. И если бы мы это сделали, мы (по крайней мере, в глазах некоторых людей) стали бы крутыми гуру. А другие бы подумали, что мы зря тратим время и ресурсы. Как обычно бывает в нашей отрасли, здесь следует найти компромисс. Давайте копнём глубже.
Технологии развиваются быстро, мы все это знаем. Как же нам оставаться впереди остальных, но не гнаться за каждой блестящей новинкой? Интересно, что погоня за каждой новинкой имеет негативный оттенок, а пребывание на острие технологий - позитивный. Я думаю, что эти вещи тесно связаны. Изучение новинок часто предвестник того, что вы в курсе текущих трендов. Конечно, если окажется, что новинка – это какой-нибудь Silverlight, вам нужно иметь возможность бросить её так же быстро, как вы за неё ухватились.
Схватить блестяшку и впоследствии знать о ней больше остальных - это может принести пользу нашей карьере. Конечно, если мы будем гоняться за каждой новинкой, мы можем обнаружить, что мало знаем о чём-либо вообще. Но давайте поговорим о том, что значит быть в курсе технологий.
Всё, что это на самом деле означает, - это делать что-то лучше, чем другие люди. Вам нужно быть впереди всех? Нуууу… «Это зависит». Многие успешные карьеры были построены без изучения новинок и без игры на опережение. Нам не обязательно знать новейшие и лучшие технологии, чтобы добиться успеха. Мы можем построить довольно успешную карьеру, специализируясь на устаревших технологиях. Если вам это в кайф, вперёд!
Однако многим из нас нравятся новые блестяшки, поэтому сосредоточимся на том, как вы можете опережать других в разработке.
Это наш путь обучения, такой, каким мы его определили. Это представление о том, что, если мы в курсе трендов, мы попадаем в верхний процент людей, которые знают о них. Именно сюда многие из нас стремятся, потому что:
- мы боимся остаться позади,
- мы боимся чего-то не знать,
- мы боимся быть наименее информированными людьми в компании, и т.п.
Наша потребность оставаться впереди всех, по крайней мере отчасти, вызвана страхами. Однако есть и другие движущие силы. Иногда мы стремимся быть впереди всех, потому что:
- мы хотим зарабатывать больше денег,
- мы хотим, чтобы нас считали успешными по каким-то показателям,
- мы получаем удовольствие от новейших технологий и получаем удовольствие от их изучения: «Ух, ты! Блестяшка!»
Всё это реальные опасения и реальные мотиваторы. У вас может быть ещё много других. Но как же выбрать стоящую новинку?
Окончание следует…
Источник: https://helenjoscott.iss.onedium.com/how-can-you-stay-ahead-of-the-curve-as-a-developer-a27d728980a2
Автор оригинала: Helen Scott
День девятьсот шестьдесят девятый. #Оффтоп #Обучение
Как Быть Лучше Всех как Разработчик? Окончание
Начало
Как узнать, какую новинку выбрать?
Да никак! Мы, вероятно, можем предположить, что новинка потенциально может решить наши проблемы. Однако мы не можем изучать все новинки и таким образом быть в курсе всех возможных трендов. Поэтому нам нужно с умом выбирать новинки, особенно в сфере технологий. Выберите, в чём хотите быть впереди, и сфокусируйтесь на этом. Нужно сосредоточиться на этой сфере, но всегда быть готовым изменить направление, поскольку ветер изменчив, и новинка, на которую вы так надеялись, может потерять популярность.
Тогда у вас есть выбор: продолжить изучать ту блестяшку, которую вы выбрали, или перейти к следующей теме, в которой вы хотите быть впереди всех.
Как оставаться впереди?
Банальный ответ: упорным трудом. Однако давайте разберёмся, потому что есть некоторые вполне реальные и осязаемые вещи, которые мы можем делать. Вот те, которые подходят мне, ваш список может быть длиннее или короче.
Часто мы можем подогнать их под наш график. Мы можем:
- читать посты в блогах,
- смотреть видео,
- слушать доклады на конференциях.
Всё это требует времени, но всё это пассивно. Если мы потратим на это время, мы соберём несколько кусочков полезной информации, которая поможет нам опередить приближающийся поезд. Однако этого недостаточно.
Есть несколько более активных действий, которые мы можем выполнить и которые потребуют от вас больше времени, но, возможно, принесут более ощутимую награду с точки зрения понимания предмета. Мы можем:
- читать посты в блогах,
- смотреть видео,
- слушать доклады на конференциях…
…Но делать это активно. То есть использовать полученные знания и применять их к чему-то в реальном мире. Поиграть с новой игрушкой - это первый шаг. Такие вопросы как:
- Какие проблемы она решает?
- Чью жизнь облегчает (допустим, что облегчает)?
- Где её можно применить в нашем мире?
- Какие есть конкуренты?
- Где её нельзя применить или в каких случаях она не сработает?
Это поможет вам «потыкать блестяшку палкой» и сформулировать некоторые мысли о том, ЧТО вы узнали. Создание контента на тему, по моему опыту, является одним из лучших способов быть впереди в теме. Это помогает закрепить знания в голове, и даёт дополнительный бонус в том, что может помочь кому-то ещё в сообществе. Эти люди могут не хотеть быть впереди всех, но хотели бы узнать о новинках и использовать их в своей работе.
Как находить время, чтобы быть впереди всех?
Как и всё, что соперничает за наше время, изучение новинок требует тщательной расстановки приоритетов. Мы не можем рассчитывать на то, что сможем быть впереди всех в чём-либо, если не найдём времени на изучение этого. Конечно, наше время – дефицит. Но мы можем искать возможности для обучения как в профессиональной, так и в личной сфере.
Многие работодатели рады, что мы тратим часть своего рабочего времени на изучение чего-то нового, особенно если это может принести им пользу в долгосрочной перспективе. Это привилегия, и не у всех она есть, но многие компании осознают тот факт, что нам нужно время, чтобы отточить навыки в некоторых областях, и неспособность дать это время принесёт ущерб как сотрудникам, так и потенциально продуктам компании.
Мы также можем использовать для этого своё личное время. Оно вам надо? Только вы можете ответить на этот вопрос. Если это приносит пользу лично вам и вашей карьере, возможно, это стоит того. Это путь, который может принести существенные выгоды. В итоге всё зависит от вас, вашего выбора понравившейся блестяшки и вашего графика.
Источник: https://helenjoscott.iss.onedium.com/how-can-you-stay-ahead-of-the-curve-as-a-developer-a27d728980a2
Автор оригинала: Helen Scott
Как Быть Лучше Всех как Разработчик? Окончание
Начало
Как узнать, какую новинку выбрать?
Да никак! Мы, вероятно, можем предположить, что новинка потенциально может решить наши проблемы. Однако мы не можем изучать все новинки и таким образом быть в курсе всех возможных трендов. Поэтому нам нужно с умом выбирать новинки, особенно в сфере технологий. Выберите, в чём хотите быть впереди, и сфокусируйтесь на этом. Нужно сосредоточиться на этой сфере, но всегда быть готовым изменить направление, поскольку ветер изменчив, и новинка, на которую вы так надеялись, может потерять популярность.
Тогда у вас есть выбор: продолжить изучать ту блестяшку, которую вы выбрали, или перейти к следующей теме, в которой вы хотите быть впереди всех.
Как оставаться впереди?
Банальный ответ: упорным трудом. Однако давайте разберёмся, потому что есть некоторые вполне реальные и осязаемые вещи, которые мы можем делать. Вот те, которые подходят мне, ваш список может быть длиннее или короче.
Часто мы можем подогнать их под наш график. Мы можем:
- читать посты в блогах,
- смотреть видео,
- слушать доклады на конференциях.
Всё это требует времени, но всё это пассивно. Если мы потратим на это время, мы соберём несколько кусочков полезной информации, которая поможет нам опередить приближающийся поезд. Однако этого недостаточно.
Есть несколько более активных действий, которые мы можем выполнить и которые потребуют от вас больше времени, но, возможно, принесут более ощутимую награду с точки зрения понимания предмета. Мы можем:
- читать посты в блогах,
- смотреть видео,
- слушать доклады на конференциях…
…Но делать это активно. То есть использовать полученные знания и применять их к чему-то в реальном мире. Поиграть с новой игрушкой - это первый шаг. Такие вопросы как:
- Какие проблемы она решает?
- Чью жизнь облегчает (допустим, что облегчает)?
- Где её можно применить в нашем мире?
- Какие есть конкуренты?
- Где её нельзя применить или в каких случаях она не сработает?
Это поможет вам «потыкать блестяшку палкой» и сформулировать некоторые мысли о том, ЧТО вы узнали. Создание контента на тему, по моему опыту, является одним из лучших способов быть впереди в теме. Это помогает закрепить знания в голове, и даёт дополнительный бонус в том, что может помочь кому-то ещё в сообществе. Эти люди могут не хотеть быть впереди всех, но хотели бы узнать о новинках и использовать их в своей работе.
Как находить время, чтобы быть впереди всех?
Как и всё, что соперничает за наше время, изучение новинок требует тщательной расстановки приоритетов. Мы не можем рассчитывать на то, что сможем быть впереди всех в чём-либо, если не найдём времени на изучение этого. Конечно, наше время – дефицит. Но мы можем искать возможности для обучения как в профессиональной, так и в личной сфере.
Многие работодатели рады, что мы тратим часть своего рабочего времени на изучение чего-то нового, особенно если это может принести им пользу в долгосрочной перспективе. Это привилегия, и не у всех она есть, но многие компании осознают тот факт, что нам нужно время, чтобы отточить навыки в некоторых областях, и неспособность дать это время принесёт ущерб как сотрудникам, так и потенциально продуктам компании.
Мы также можем использовать для этого своё личное время. Оно вам надо? Только вы можете ответить на этот вопрос. Если это приносит пользу лично вам и вашей карьере, возможно, это стоит того. Это путь, который может принести существенные выгоды. В итоге всё зависит от вас, вашего выбора понравившейся блестяшки и вашего графика.
Источник: https://helenjoscott.iss.onedium.com/how-can-you-stay-ahead-of-the-curve-as-a-developer-a27d728980a2
Автор оригинала: Helen Scott
День девятьсот семидесятый. #NuGet
Генерация QR Кодов в .NET
QR коды сегодня повсюду, поэтому часто требуется возможность их генерировать. Сегодня расскажу вам про полезный пакет Net.Codecrete.QrCodeGenerator, позволяющий генерировать QR коды из текста или массива байт буквально в 2 строчки. Библиотека создана для .NET Standard 2.0 и поэтому работает на большинстве современных платформ .NET (.NET Core, .NET Framework, Mono и т.д.).
Основные особенности
- Поддерживает кодирование всех 40 версий (размеров) и всех 4 уровней коррекции ошибок в соответствии со стандартом QR Code Model 2.
- Форматы вывода: чистые пиксели QR символа, строка SVG XML, растровое изображение.
Параметры
- Вы можете указать минимальный и максимальный разрешённый номер версии, и библиотека автоматически выберет наименьшую версию в диапазоне, который соответствует данным.
- Вы можете указать шаблон маски вручную, либо библиотека автоматически оценит все 8 масок и выберет оптимальную.
- Вы можете указать уровень исправления ошибок или, при желании, разрешить библиотеке повышать его, если это не увеличивает номер версии.
- Вы можете создать список сегментов данных вручную и добавить сегменты ECI.
В GitHub проекта есть пример генерации файлов в консольном приложении, но я решил, что пример на сайте более нагляден.
Добавим в проект NuGet пакет:
Генерация QR Кодов в .NET
QR коды сегодня повсюду, поэтому часто требуется возможность их генерировать. Сегодня расскажу вам про полезный пакет Net.Codecrete.QrCodeGenerator, позволяющий генерировать QR коды из текста или массива байт буквально в 2 строчки. Библиотека создана для .NET Standard 2.0 и поэтому работает на большинстве современных платформ .NET (.NET Core, .NET Framework, Mono и т.д.).
Основные особенности
- Поддерживает кодирование всех 40 версий (размеров) и всех 4 уровней коррекции ошибок в соответствии со стандартом QR Code Model 2.
- Форматы вывода: чистые пиксели QR символа, строка SVG XML, растровое изображение.
Параметры
- Вы можете указать минимальный и максимальный разрешённый номер версии, и библиотека автоматически выберет наименьшую версию в диапазоне, который соответствует данным.
- Вы можете указать шаблон маски вручную, либо библиотека автоматически оценит все 8 масок и выберет оптимальную.
- Вы можете указать уровень исправления ошибок или, при желании, разрешить библиотеке повышать его, если это не увеличивает номер версии.
- Вы можете создать список сегментов данных вручную и добавить сегменты ECI.
В GitHub проекта есть пример генерации файлов в консольном приложении, но я решил, что пример на сайте более нагляден.
Добавим в проект NuGet пакет:
dotnet add package Net.Codecrete.QrCodeGenerator --version 1.6.1Создадим простую страничку с формой, принимающей текст, который мы хотим видеть в QR коде, и отображающей сам код после отправки формы:
@model Byte[]QR код передаётся в представление в виде массива байтов и отображается как изображение base64. А вот код метода действия контроллера, обрабатывающего форму:
@using (Html.BeginForm(FormMethod.Post))
{
<label>Текст для QR кода:</label><br />
<input type="text" name="qrText" size="40" />
<button>Сгенерировать</button>
}
@if (Model != null)
{
<label>QR Код Успешно Сгенерирован:</label><br />
<img src="@string.Format("data:image/png;base64,{0}",
Convert.ToBase64String(Model))" />
}
using System.Drawing.Imaging;В методе используем статический метод
using System.IO;
using Net.Codecrete.QrCodeGenerator;
[HttpPost]
public IActionResult Index(string qrText)
{
if (string.IsNullOrEmpty(qrText))
return View();
var qr = QrCode.EncodeText(qrText, QrCode.Ecc.Medium);
var img = qr.ToBitmap(6, 1);
using var stream = new MemoryStream();
img.Save(stream, ImageFormat.Bmp);
return View(stream.ToArray());
}
EncodeText для преобразования текста в QR код. Затем преобразуем изображение в поток байт и отправляем в представление. Получаем результат, как на картинке ниже.День девятьсот семьдесят первый. #Оффтоп
Советы для Продвинутого Пользователя Git. Начало
Хорошо это или плохо, но Git превзошёл другие системы контроля версий, такие как Subversion, Perforce и ClearCase, и стал стандартом системы управления исходным кодом для современного разработчика. Если вы не знакомы ни с одной из этих систем, считайте, что вам повезло жить в эпоху простых локальных ветвлений, поддержки нескольких рабочих процессов и множества распределённых платформ хостинга репозиториев.
Хотя Git легко изучить, его постоянное развитие и широкий спектр возможностей усложняют освоение его продвинутого использования. В результате как новички, так и опытные программисты частенько (вероятно, матерясь) гуглят «как мне это сделать в Git».
В этой серии постов рассмотрим несколько команд для некоторых продвинутых сценариев при работе с репозиторием Git.
1. Клонирование и удалённые URL
Git поддерживает учётные данные Secure Shell (SSH), уникальный криптографический идентификатор для клиентов, при этом большинство ключей создается с использованием алгоритма RSA. Ключи SSH действуют как имя пользователя и пароль для удалённого экземпляра репозитория кода. Для программиста это значит, что имя пользователя и пароль придётся вводить гораздо реже.
При работе с удалёнными репозиториями вы можете случайно клонировать репозиторий, используя HTTPS URL-адрес вместо SSH. Хотя через HTTPS всё равно можно работать, но все пуши в репозиторий потребуют от вас ввода имени пользователя и пароля. Чтобы проверить адрес удалённого репозитория, вы можете использовать Git CLI:
Продолжение следует…
Источник: https://blog.jetbrains.com/dotnet/2021/09/13/advanced-git-workflow-tips/
Советы для Продвинутого Пользователя Git. Начало
Хорошо это или плохо, но Git превзошёл другие системы контроля версий, такие как Subversion, Perforce и ClearCase, и стал стандартом системы управления исходным кодом для современного разработчика. Если вы не знакомы ни с одной из этих систем, считайте, что вам повезло жить в эпоху простых локальных ветвлений, поддержки нескольких рабочих процессов и множества распределённых платформ хостинга репозиториев.
Хотя Git легко изучить, его постоянное развитие и широкий спектр возможностей усложняют освоение его продвинутого использования. В результате как новички, так и опытные программисты частенько (вероятно, матерясь) гуглят «как мне это сделать в Git».
В этой серии постов рассмотрим несколько команд для некоторых продвинутых сценариев при работе с репозиторием Git.
1. Клонирование и удалённые URL
Git поддерживает учётные данные Secure Shell (SSH), уникальный криптографический идентификатор для клиентов, при этом большинство ключей создается с использованием алгоритма RSA. Ключи SSH действуют как имя пользователя и пароль для удалённого экземпляра репозитория кода. Для программиста это значит, что имя пользователя и пароль придётся вводить гораздо реже.
При работе с удалёнными репозиториями вы можете случайно клонировать репозиторий, используя HTTPS URL-адрес вместо SSH. Хотя через HTTPS всё равно можно работать, но все пуши в репозиторий потребуют от вас ввода имени пользователя и пароля. Чтобы проверить адрес удалённого репозитория, вы можете использовать Git CLI:
> git remote -vЧтобы изменить URL для удалённого источника, вы можете использовать команду set-url. URL-адрес SSH можно найти у вашего Git провайдера. В случае репозиториев GitHub он обычно следует шаблону
origin https://github.com/user/Repo.git (fetch)
origin https://github.com/user/Repo.git (push)
[email protected]:<username>/<repository_name>.git:Вы можете снова запустить команду git remote -v, чтобы убедиться, что URL-адрес обновлён:
> git remote set-url origin [email protected]:user/Repo.git
> git remote -vПри работе в Visual Studio или Rider вы можете использовать меню Git > Manage Remotes.
origin [email protected]:user/Repo.git (fetch)
origin [email protected]:user/Repo.git (push)
Продолжение следует…
Источник: https://blog.jetbrains.com/dotnet/2021/09/13/advanced-git-workflow-tips/