Каковы реальные проблемы для разработчика, мигрирующего между языками программирования? [закрытый]
Я, наконец, сделал следующее, что имеет преимущество в том, что он не разрушительный. Кроме того, у меня нет времени на его тестирование, но я просто надеялся, что это позволит избежать прохождения каждого вложенного элемента, как в ответе @ Bitto-Bennichan, но на самом деле это неуверенно. В любом случае, он делает то, что хотел:
all_fetched = []
fetched = soup.find('div', class_='wanted')
while fetched is not None:
all_fetched.append(fetched)
try:
last = list(fetched.descendants)[-1]
except IndexError:
break
fetched = last.findNext('div', class_='wanted')
7 ответов
Самой сложной задачей (для меня) обычно является API, а не сам язык (.NET, несмотря на это). Например, я использовал C++ Microsoft и C# в течение большого количества лет (Delphi перед этим). Но я испытываю большие затруднения при начале работы на Java; даже тривиальные проекты могут взять меня некоторое время. Не потому что язык является трудным (это не), но потому что API отличаются, и расположенные по-другому.
Требуются месяцы для набирания скорость на API к точке, можно использовать его бегло, и годы, чтобы стать "хорошими" и изучить все входы и выходы языка. Это является пугающим для большого количества разработчиков, потому что в основном необходимо посвятить существенное количество (если не все) времени и усилия к работе на новом языке для становления экспертом в нем. Много раз стимул переместиться из Вашей текущей области знаний просто не там.
Для меня это было бы, находя хороших блоггеров и полезные сайты на языке. Через некоторое время Вы узнаете, где лучшие люди. Те люди и сайты являются хорошими источниками информации для изучения тонкости.
Та же парадигма намного легче, потому что это - действительно просто вопрос схватывания различных библиотек и определения местоположения их быстро, как Вы упомянули.
Если парадигмы отличаются, чем этот переключатель является более трудным. Перемещение от помех до динамического языка или процедурного на язык ООП потребует другого набора ума. Это займет больше времени, но это возможно и все еще очень хорошее осуществление.
Это может быть подобно изучению иностранных языков. Если Вы говорите на английском языке, чем перемещение в другой находящийся в латыни язык намного легче, чем движение к чему-то как греческий язык.
отъезд зоны комфорта. Я думаю, что это - одна из самых больших причин, некоторые разработчики не учат новые языки.
Но для других, это - то, что управляет ими.
Перемещение в той же парадигме относительно легко. Я нахожу, что переключение между Java и.NET, безболезненной, потому что обе платформы предлагают схожую функциональность и подобные библиотеки. Но переключение парадигм могло быть реальной проблемой.
Моим студентам обычно нелегко идти в Функциональные и Логические языки после изучения Java даже при том, что функциональное и логическое программирование легче.
Другая проблема переключается между типами приложений. Например, если Вы приучены к создаванию настольных приложений в Java, затем внезапно пытаются создать веб-приложения в.NET, переключатель тверд, потому что Вы не только учите новые языки, но новые поля программирования.
Другая проблема является комплектами инструментальных средств, которые доступны для конкретного языка. Java и.NET имеют подобные инструменты, но с некоторыми различиями. Если Вы учились программе с помощью Visual Studio затем, возможно, что функции Visual Studio становятся запутанными с языком. Я вижу, что студенты имеют эту проблему все время. Когда Вы переключаетесь на Java и нет никакого эквивалентного пункта меню мастера в новом IDE, он мог вызвать проблемы.
Я рекомендую людям, учащимся программирующий для изучения базового понятия парадигмы, а не определенного языка, потому что это делает Вас более портативными в будущем. У человека, довольного Объектно-ориентированными Понятиями, будет более легкая временная коммутация между Java и.NET или Python, чем человек, который простой изучил, как программировать в C#.
Точно так же, как изучение нового естественного языка для меня самая большая проблема заключается на типичных конструкциях, которые необходимо сделать для решения проблемы.
Я знаю, что, возможно, учась, "в то время как" или "для" циклов на нескольких языках не являются настолько трудными - но когда Ваша проблема повышается один уровень абстракции (выполняют итерации через этот массив) Вы будете использовать" [" вместо" (" и наоборот.
Кривая обучения может быть еще более крутой, если, помимо изучения нового языка, необходимо изучить новую платформу. О том, когда я пошел от typícal ASP.NET до MVC (использующий NVelocity), я отчасти чувствовал меня полностью потерянный - все мое знание о том, как решить типичные проблемы с управлением asp.net, нужно было забыть.
Наконец, самая сложная задача происходит, когда Вы изменяетесь между языками с различными парадигмами - потому что Вы больше не можете думать таким же образом для решения проблемы. Как - при перемещении от C# до Пролога, вместо того, чтобы думать в функциях, аргументах, иерархии классов, etcs... Я должен был думать только в состояниях, события, связанные с изменениями данных и объединением в цепочку события через рекурсию - это было безумие, но я мог закончить свою университетскую домашнюю работу.
Во-первых, вот еще один блог, который может оказаться полезным.
build-tools-maven-and-coldfusion
Я не пробовал создавать ColdFusion с Maven, но у меня есть опыт с управлением сборками Maven для большой компании. Вы должны учесть несколько вещей.
Структура проекта
Файлы cfm и cfc Coldfusion должны быть помещены в src / main / resources, чтобы они были объединены в jar (упомянутый выше блог отменяет соглашение Maven, чтобы поместить их в src. это нормально, но может возникнуть проблема, если позже вам понадобится добавить что-нибудь еще в проект).
Я бы, вероятно, сохранил файлы cfc и cfm в отдельных проектах с соответствующими объявлениями зависимостей, чтобы связать их, это сохраняет ваши проекты cfc как библиотеки и помогает повторно использовать. Также стоит учитывать степень детализации проектов cfc. Обычно Maven ' s управление зависимостями помогает уменьшить размер артефактов, не беспокоясь о поиске всех jar-файлов.
Развертывание
Самый простой способ доставить артефакты - использовать maven-war-plugin для Создайте войну, содержащую ваши артефакты и все их транзитивные зависимости. Это делает каждое приложение самодостаточным, что может быть полезно. Обратной стороной этого является то, что вам придется многократно объединять одни и те же артефакты, и они могут быть довольно большими. Чтобы смягчить это, вы можете либо использовать плагин сборки для создания пользовательских пакетов, исключая общие компоненты, либо указать, что определенные компоненты (например, ColdSpring) являются областью , предоставленной , это означает, что они не будет включен в войну.
Управление версиями
Maven поощряет распространение зависимостей, по умолчанию каждое объявление зависимости имеет версию, это может вызвать проблемы с обслуживанием, особенно если вы хотите поднять версию внешней зависимости. Вы можете смягчить это, определив родительский POM или POM «приложения». Любой из них будет иметь раздел dependencyManagement, в котором объявляются сведения (groupId, artifactId и версия) для общих артефактов. Любой POM, унаследованный от родителя, не должен объявлять версию зависимости, поскольку он будет унаследован (обратите внимание, это не означает, что все дочерние элементы будут иметь все зависимости, только то, что те, которые объявляют зависимость, не должны объявлять версию). Если вы определяете проект «app» с упаковкой «pom» и разделом dependencyManagement, вы можете ссылаться на него с помощью scope import (начиная с Maven 2.0.9 и далее), это импортирует раздел dependencyManagement из проекта «app» в POM проекта. Для получения дополнительных сведений см. документацию по зависимостям .
Если вы объявите зависимость с областью видимости в разделе dependencyManagement, эта область будет унаследована, если она не будет переопределена в дочернем POM. Относительно раздела развертывания выше, это означает, что вы можете объявить область общих библиотек , предоставленную в родительском элементе, чтобы гарантировать, что они не объединены в каждое приложение.
Соглашения об именах Вам понадобится соглашение об именах для пакетов, чтобы избежать конфликтов. Вероятно, лучше всего следовать соглашению Maven и использовать групповые идентификаторы Java-пакета (org.apache.maven для maven.apache.org) и имя jar-файла для артефакта. В соответствии с этим соглашением groupId будет «org.coldspringframework» и artifactId «coldspring» для ColdSpring.
Может потребоваться дальнейшее различие для всей компании. Например, если у вас есть веб-группа и основная группа, вы можете дать веб-группе идентификаторы groupIds com.mycompany.web. * И основной команде com.mycompany.core. *
Управление зависимостями
. для добавления ваших пакетов CFC в репозиторий Maven, например Nexus , чтобы они были доступны для других сборок на предприятии.
Если вы хотите хранить пакеты CFC отдельно от jar-файлов. Вы можете указать собственный тип упаковки, чтобы они не смешивались с какими-либо артефактами Java. API более сложен, но самая сложная область - найти путь через все фреймворки.
Кроме того, необходимость использовать Eclipse в качестве IDE - это шаг назад с точки зрения стабильности и надежности по сравнению с Emacs. Возможности Eclipse действительно впечатляют, но ошибки в IDE вызывают постоянные хлопоты.