Спасибо за ссылку и информацию. Там два релиза этого проекта Notepad++ для программиста было выпущено. github.com/simonsteele/pn/releases
Самый недавний это 3 Dec 2016.
Simon Steele работал над этим проектом 15 лет.
Очень интересный рассказ со всеми подробностями. Захватывающая история.
Хорошая стилистика. Актуальность данной статьи не вызывает сомнения, поскольку следуя вашим советам, многие смогут попытаться в будущем поступить.
Мне особенно понравились ваши подробные рассуждения о скрытых возможностях и подводных камнях. Ваши рекомендации будут несомненно полезны
поступающим. С интересом прочитал. Ваши рассуждения действительно мотивируют на достижение поставленных целей и осуществление мечты. То как вы описываете ваше общение и тщательную подготовку вызывает большой интерес.
Спасибо за ваши труды и вдохновение.
Ищу любую работу в сфере IT, на любую даже минимальную зарплату.
Квалификация: диплом(тема диплома ИИ), сертификаты по java среднего уровня, опыт работы, реально участвовал в проектах ИИ (нейросети) — Daimler Benz Forschung, Daimler AG.
Пожалуйста, если кто может реально помочь найти работу напишите мне.
Различие между фреймворком и языком программирования мне известны.
Но на раннем этапе карьеры редко кто задаётся вопросом об этой разнице.
Что местами у человека опытного может возникнуть диссонанс я думал в момент написания, но не сумел найти быстрого решения как исправить ситуацию.
Mep3avec, тут я с вами согласен. Для удобства прочтения нужно будет запилить навигацию, хоть простенькую по публикации. Но всё сразу не сделать. Значительные улучшения — это не быстрый процесс.
Это только холивар на тему какие альясы вы используете.
То что я назвал Qt языком программирования, а не фремвоком?
Qt, да по некоторым определениям фремвок, на котором уже разговаривают.
С другой стороны любой язык программирования можно называть синтаксическим сахаром. Это смотря с какой стороны смотреть и как-то обозначить точку отсчета в некой системе координат рассуждений. В предыдущем ответе я сказал гнусную ложь, вернее сказку, даже не всю сказку, а только её часть поэтому пост заминусовали. Только вот раскаяния как-то не приходит.
ru.wikipedia.org›Smalltalk
Smalltalk ([ˈsmɔːltɔːk]) — объектно-ориентированный язык программирования с динамической типизацией, основанный на идее посылки сообщений, разработанный в Xerox PARC Аланом Кэйем, Дэном Ингаллсом, Тедом Кэглером, Адель Голдберг, и другими в 1970-х
Спасибо за интересный обзор «Самые редкие и самые дорогие языки».
Самые редкие — это экзотические языки программирования.
Под «самые дорогие языки» — у вас имеется в виду самые высокооплачиваемые специалисты знающие определенные языки программирования.
«Самые дорогие» — это дорогие в изучении, в затратах на изучение.
Не факт, что они самые прибыльные.
Можно рассмотреть по прибыльности для компаний. Для компании Oracle самым прибыльным является язык Java, как очень распространенный на земном шаре.
Для Microsoft прибыльным является C#.
Ассемблер — прибыльный, но очень тяжелый в освоении язык.
Бизнес не может «хотеть» или «не хотеть». Это некоторая фантазия об объекте исследования. Бизнес может выступать в роли субъекта?
Надо пойти, уговорить бизнес. Сам «бизнес» вы никак не сможете уговорить. Пока нет определения бизнеса — это некоторое абстрактное понятие.
Статья интересная. Но, с моей точки зрения, она в основном про какое-то «садо-мазо». О плохой архитектуре и не выстроенных коммуникациях внутри системы.
Не имею в виду плохую архитектуру некого кода, под плохой архитектурой в данном случае я имею в виду плохую архитектуру самого взаимодействия в системе, нарушение коммуникаций и коллизии. Отсюда и непонимание между разработчиками разных поколений. Это в конечном счете может отразиться на связи исполнитель — заказчик.
По моему мнению некоторые знания объектно-ориентированного программирования, SOLID например, можно применять не только в коде, но и в реальной жизни. Это выглядит довольно странно, что сами разработчики хорошо разбираясь в архитектуре, не могут выстроить и реализовать архитектуру нормальных отношений и коммуникаций в команде. Ну да они же не психотерапевты и не «гигапевты».
rcanedu, в общих словах вы правильно описываете довольно распространенную ситуацию.
То есть вы обозначаете некоторую проблему, но не предлагаете пути её решения. Только сама локализация некоторой коллизии не приводит самостоятельно к разрешению конфликтной ситуации.
Narical, те моменты которые затрагиваются в ваших ссылках касаются более глубокого погружения в git. То есть многие моменты исследуют философию git и могут касаться разработчиков самого git. И это не очень простые темы. Там уже несколько иной уровень.
Прог вхождения в эту тему будет запредельно высок >>>
Narical, ваша критика справедлива.
Не буду с вами спорить. Хотел написать небольшую шпаргалку по git, а получилась довольно длинная публикация. Перестарался. Но без объяснения тех или иных терминов и некоторой вводной теоретической части не обойтись. Немного перестарался. Более того, я улучшаю публикацию понемногу и она будет еще длиннее.
Спасибо за интересную публикацию. Реальность жизни. Мне следовало прочитать вашу статью 32 года назад. Некоторые выводы в статье всё-же во многом субъективны. Онлайн курсы, машинное обучение в плане практики может дать очень многое. Выбор своего пути мы делаем часто интуитивно, а не руководствуемся расчетами и статистикой. В плане обучения стало в некотором смысле легче учиться, потому как информация более доступна и открыта, но её потоки увеличились. В плане обучения, по моему мнению больше времени нужно уделять практике в начале своего пути. Практический, как и теоретический опыт накапливается с годами. К вопросу об обучении, то теория и теоретические знания необходимые специалисту устаревают довольно медленно. Некоторые фундаментальные знания, заложенные учеными еще прошлого века продолжают сохранять актуальность на сегодняшний день. Ключевой момент тут, как эти знания преподнести, чтобы они лучше усваивались, были яснее и понятнее. Если посмотреть с другой стороны, со стороны обучающегося, то важным становится вопрос, как быстрее усваивать и применять полученные знания. То есть вы сами, учитесь выстраивать свои методы самообучения. Время — очень ценный и не бесконечный ресурс для человека.
$ssh git@github.com
ssh: connect to host github.com port 22: Operation not permitted
Доступ есть. Есть репозитории. Но я их отправляю по https://, хотя и по ssh: тоже иногда получается.
Ссылку в основном делаю так: $git remote add имя_ссылки https://github.com/имя_пользователя/имя_репозитория.git
Вместо origin использую удобное имя.
PS. Иногда всё нормально. Иногда «permission denied».
Статья хорошая.
Но в статье можно было-бы рассказать еще про токены, какие токены генерируются. Для чего.
Про роли в проекте. Нет я конечно понимаю, что тогда получится очень длинно.
И вы упомянули ссылки на хеш. Продолжите, как их можно использовать. Что можно использовать для ссылки первые 3 буквы хеша. И еще
версии проектов (commit)
— это не совсем точное определение. commit — это что-то вроде ссылки на сделанные изменения. То есть это ссылка на разницу. Точного определения я сам сейчас не вспомню. Нужно будет поискать.
Расскажите что такое HEAD. И о git checkout HEAD^, о ветках, о слиянии веток.
Спасибо за публикацию.
У меня получилось по вашей статье. Но только до этого момента:
$ git push -u origin master
ssh: connect to host github.com port 22: Operation not permitted
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Напишите побольше о правах доступа. Почему может возникнуть такая ошибка.
И даже по https — тоже та же ошибка. Порт не заблокирован.
Согласен. Нужно будет еще раскрыть более подробно тему интерфейсов, вложенных интерфейсов, абстрактных классов применительно к внутренним классам и затронуть тему наследования при этом. Позже допишу. Примеры кода еще не готовы.
Благодарю вас за такой труд. Выскажу некоторые пожелания.
… позволяет легко определять “что куда импортируется”
В этом блоке у вас получается сразу довольно сложная схема.
Она может быть как-то упрощена или отфильтрована?
Блок-схему выбранного файла.
— очень хорошо, полезно.
можно изучить их интеграцию между собой.
Тут также, если это UML диаграммы, то можно ли будет их как-то отфильтровать, так чтобы сразу не выводить такую сложную схему. А как-то её упростить. С возможностью не выводить всю схему. С возможность скрыть/показать определенные связи.
Вы делаете полезный инструмент. Благодарю за публикацию.
Интересная публикация. Благодарю за перевод и ссылки.
Нужно наверное дать полную ссылку www.reddit.com/r/proceduralgeneration
Это скорее всего была локальная ссылка. После слова «В сабреддите. ».
Благодарю за ваш труд.
github.com/simonsteele/pn/releases
Самый недавний это 3 Dec 2016.
Simon Steele работал над этим проектом 15 лет.
Хорошая стилистика. Актуальность данной статьи не вызывает сомнения, поскольку следуя вашим советам, многие смогут попытаться в будущем поступить.
Мне особенно понравились ваши подробные рассуждения о скрытых возможностях и подводных камнях. Ваши рекомендации будут несомненно полезны
поступающим. С интересом прочитал. Ваши рассуждения действительно мотивируют на достижение поставленных целей и осуществление мечты. То как вы описываете ваше общение и тщательную подготовку вызывает большой интерес.
Спасибо за ваши труды и вдохновение.
Мои публикации здесь: Опровержение мудреца. Анализируем предложенный алгоритм
Работа с распределенной системой контроля версий Git на примере GitHub
Внутренние и вложенные классы java
Ищу любую работу в сфере IT, на любую даже минимальную зарплату.
Квалификация: диплом(тема диплома ИИ), сертификаты по java среднего уровня, опыт работы, реально участвовал в проектах ИИ (нейросети) — Daimler Benz Forschung, Daimler AG.
Пожалуйста, если кто может реально помочь найти работу напишите мне.
Но на раннем этапе карьеры редко кто задаётся вопросом об этой разнице.
Что местами у человека опытного может возникнуть диссонанс я думал в момент написания, но не сумел найти быстрого решения как исправить ситуацию.
То что я назвал Qt языком программирования, а не фремвоком?
Qt, да по некоторым определениям фремвок, на котором уже разговаривают.
С другой стороны любой язык программирования можно называть синтаксическим сахаром. Это смотря с какой стороны смотреть и как-то обозначить точку отсчета в некой системе координат рассуждений. В предыдущем ответе я сказал гнусную ложь, вернее сказку, даже не всю сказку, а только её часть поэтому пост заминусовали. Только вот раскаяния как-то не приходит.
Некоторые направления Smalltalk продолжают развиваться в настоящее время.
mou пишет в своей публикации на хабре «Как попробовать Smalltalk на вкус»
arielf пишет в своей публикации «Как изучение Smalltalk может улучшить ваши навыки программиста»
Вы не включили в свое исследование Qt.
Спасибо за интересный обзор «Самые редкие и самые дорогие языки».
Самые редкие — это экзотические языки программирования.
Под «самые дорогие языки» — у вас имеется в виду самые высокооплачиваемые специалисты знающие определенные языки программирования.
«Самые дорогие» — это дорогие в изучении, в затратах на изучение.
Не факт, что они самые прибыльные.
Можно рассмотреть по прибыльности для компаний. Для компании Oracle самым прибыльным является язык Java, как очень распространенный на земном шаре.
Для Microsoft прибыльным является C#.
Ассемблер — прибыльный, но очень тяжелый в освоении язык.
Надо пойти, уговорить бизнес. Сам «бизнес» вы никак не сможете уговорить. Пока нет определения бизнеса — это некоторое абстрактное понятие.
Статья интересная. Но, с моей точки зрения, она в основном про какое-то «садо-мазо». О плохой архитектуре и не выстроенных коммуникациях внутри системы.
Не имею в виду плохую архитектуру некого кода, под плохой архитектурой в данном случае я имею в виду плохую архитектуру самого взаимодействия в системе, нарушение коммуникаций и коллизии. Отсюда и непонимание между разработчиками разных поколений. Это в конечном счете может отразиться на связи исполнитель — заказчик.
По моему мнению некоторые знания объектно-ориентированного программирования, SOLID например, можно применять не только в коде, но и в реальной жизни. Это выглядит довольно странно, что сами разработчики хорошо разбираясь в архитектуре, не могут выстроить и реализовать архитектуру нормальных отношений и коммуникаций в команде. Ну да они же не психотерапевты и не «гигапевты».
rcanedu, в общих словах вы правильно описываете довольно распространенную ситуацию.
То есть вы обозначаете некоторую проблему, но не предлагаете пути её решения. Только сама локализация некоторой коллизии не приводит самостоятельно к разрешению конфликтной ситуации.
А есть цель написать простыми словами и рассказать о практическом применении.
Прог вхождения в эту тему будет запредельно высок >>>
Не буду с вами спорить. Хотел написать небольшую шпаргалку по git, а получилась довольно длинная публикация. Перестарался. Но без объяснения тех или иных терминов и некоторой вводной теоретической части не обойтись. Немного перестарался. Более того, я улучшаю публикацию понемногу и она будет еще длиннее.
Доступ есть. Есть репозитории. Но я их отправляю по
https://, хотя и по ssh: тоже иногда получается.Ссылку в основном делаю так: $git remote add имя_ссылки
https://github.com/имя_пользователя/имя_репозитория.gitВместо origin использую удобное имя.
PS. Иногда всё нормально. Иногда «permission denied».
Статья хорошая.
Но в статье можно было-бы рассказать еще про токены, какие токены генерируются. Для чего.
Про роли в проекте. Нет я конечно понимаю, что тогда получится очень длинно.
И вы упомянули ссылки на хеш. Продолжите, как их можно использовать. Что можно использовать для ссылки первые 3 буквы хеша. И еще — это не совсем точное определение. commit — это что-то вроде ссылки на сделанные изменения. То есть это ссылка на разницу. Точного определения я сам сейчас не вспомню. Нужно будет поискать.
Расскажите что такое HEAD. И о
git checkout HEAD^, о ветках, о слиянии веток.У меня получилось по вашей статье. Но только до этого момента:
Напишите побольше о правах доступа. Почему может возникнуть такая ошибка.
И даже по https — тоже та же ошибка. Порт не заблокирован.
У вас небольшая ошибка в тексте:
Она может быть как-то упрощена или отфильтрована?
— очень хорошо, полезно.
Тут также, если это UML диаграммы, то можно ли будет их как-то отфильтровать, так чтобы сразу не выводить такую сложную схему. А как-то её упростить. С возможностью не выводить всю схему. С возможность скрыть/показать определенные связи.
Вы делаете полезный инструмент. Благодарю за публикацию.
Нужно наверное дать полную ссылку www.reddit.com/r/proceduralgeneration
Это скорее всего была локальная ссылка. После слова «В сабреддите. ».
Благодарю за ваш труд.