Смотря что конкретно понимается под "проектом"... если это, скажем так, нечто, подлежашее сборке, то есть такая штука, как maven с его архетипами, или тот же gradle с плагинами/template-ами. Если нодовские проекты, то есть, например, yeoman.io . Но если нужно просто создать некую структуру папок, то это может быть из пушки по воробьям ;) Укажите точнее, о каких проектах речь, нужно ли учитывать какие-то зависимости и т.д., иначе просто трудно посоветовать что-то определенное.
Макс: Вполне может быть, что предлагаемый Вами Match для Шарпа даже лучше, чем Split. Я с конкретно .NET-овскими регулярками последний раз имел дело лет пять назад, так что детали реализации уже сильно подзабылись - пример набросал "на коленке", исходя из того, что для непойми-каких-строк шанс, что, по крайней мере, структура делимитеров регулярна, всегда немного выше, чем для данных :) Но, конечно, всегда остается опасность, что одно вдруг встретится в другом, и никто не подумал его заискейпить. Так что, да... если только есть такая возможность, самостоятельно определить формат, ей лучше воспользоваться, т.к. это наверняка сэкономит кучу нервных клеток при разборе :)
Не только могут, но и активно удаляют! Например, я часто так поступаю, чтоб не засорять Тостер ответами, которые либо ничего не добавляют по сути вопроса, либо просто и очевидно не нужны автору вопроса, уже выбравшему для себя "простой неправильный ответ" :)
Dmitry07: Например, equalsIgnoreCase() Но это мало что меняет с т.з. производительности: решение абсолютно зубодробительное, даже если оно и работает... хорошо бы переделать.
Михаил: Конкретно, увы, не отвечу - сам такого не делал. Но эта штука, по сути, ориентирована на сбор и анализ логов (в т.ч. с кастомными форматами) с разнообразных систем. Если у Вас ОДИН сервер и свои известные структуры данных, возможно, это будет из пушки по воробьям и лучше просто запилить самостоятельно, на том же Эластике.
Не стоит экстраполировать (личный?) печальный опыт на ситуацию в целом. Описанное Вами, безусловно, имеет место быть, но бывает и прямо противоположная мотивация. У нас, например, такого требования в вакансии нет, но если на собеседование приходит надутый индюк, лопающийся от собственной серьезности, оно, обычно, проходит задорно и заканчивается быстро. Ибо чувство юмора - признак незашоренности мышления и способности подвергать сомнению "общепринятые истины". А это - как раз то, что нужно для молодой динамичной команды, которая должна сворачивать горы, а не отсиживать стулья )) Однако, это качество, разумеется, вторично по сравнению с непосредственной профпригодностью ))
Что в вашем понимании "долго"? "Перевести" 1-2 проекта на maven или gradle, даже если там кругом мегакостыли, это день, максимум два работы. Заодно вычистятся костыли, появится уверенность в завтрашнем дне относительно сторонних зависимостей, короче, можно будет перестать нервничать и начать уверенно собирать. Еще лучше прикрутить к этому Jenkins и юниттесты (это можно делать постепенно). Такая инвестиция отобьется тем быстрее, чем больше народу будет работать над кодом. Дописывание скриптов для скриптов - просто заментание проблемы под ковер ))
Если интересно, изучите физику, электротехнику, электронику и программирование... все изучается в ВУЗах, на лекциях и по толстым учебникам. И тогда все узнаете и про устройство деталей, и про устройство плат, и про то, как сконструировать и собрать устройство. А если потом еще пойдете работать по специальности, наверняка быстро наберетесь опыта, достаточного для того, чтоб сделать это самостоятельно. Если же такой путь кажется слишком сложным, то лучше купите готовое, т.к. современные устройства размером с браслет, даже самые примитивные, настолько сложны и высокотехнологичны, что разобраться с ними и собрать по какому-нибудь туториалу просто нереально ))
AxenovSergey: Вот тут обсуждалась похожая тема. Принципиальных отличий "тут" и "там" нет, так что, все сказанное там про необходимые навыки точно так же, если не больше, актуально и для эмиграции. По сути Вашего вопроса... Помимо чисто профессиональных навыков основное, как уже сказали - язык. Менеджер, это прежде всего, работа с людьми, а потом уже с цифрами и отчетами. А из всяких бумажек важен, по сути, только диплом, и только в смысле формальности для самой процедуры. Работодателя же интересуют скилы и только скилы. Если они есть, не вопрос. Если нет, никакие бумажки не помогут. Кроме того, настройтесь заранее на то, что даже при наличии хорошего опыта, Вы начнете в лучшем случае с ассистента... но, вероятнее, с разработчика. Это не "дедовщина"... Вам просто нужно будет по крайней мере привыкнуть к местной специфике, менталитету людей, принципам построения рабочих отношений... да просто банально выучить профессиональный сленг и т.д., прежде, чем Вам кто-то доверит бабки (проект). Ну, а насколько это сложно или просто - каждый решает для себя сам. Как говорится, глазки боятся, а ручки (и мозги) делают ))
xfg: "так не бывает"
На самом деле еще как бывает :) ...если программист накосячил с синхронизацией ресурсов... что случается сплошь и рядом :) Ибо в большинстве современных распространенных ЯП всякие локи, семафоры и мютексы нужно ставить ручками и делать это правильно. А что конкретно будет - зависит от компилятора и/или VM и набора инструкций и архитектуры процессора, на котором все это выполняется и даже от расположения звезд. В подавляющем большинстве случаев если неатомарные инструкции одного потока "вклинятся" между инструкциями из другого, код может увидеть в памяти вместо ожидаемых совершенно левые значения. Это приведет к непредсказуемой ошибке в программе (если речь о данных) или к попытке обратиться к памяти, не принадлежащей процессу (если речь об указателе), за что ОС этот процесс неминуемо жестоко покарает... а если такой косяк случится в коде какого-нибудь драйвера, работающего с железом, то вааще может упасть вся ОС или даже физически повредиться железо. Короче, ошибки в многопоточности - весьма распространенное явление и обычно отстреливают ногу по самые уши ))
Dmitry07: 'пустота' перед методом означает всего навсего, что речь идет о вызове метода ТОГО ЖЕ САМОГО класса, в котором этот вызов происходит. На ее месте всегда подразумевается некий квалификатор метода (где его искать) - либо имя класса, если метод статический, либо ссылка на экземпляр класса. Внутри одного класса и то и другое обычно опускается, чтоб не загромождать код. И есть еще вариант 'пустоты' при вызове статического метода ДРУГОГО класса, который был импортирован, например:
С точки зрения компилятора это абсолютно все равно - ему важно только, чтоб было однозначно понятно, о котором методе речь. А для удобства программиста IDE как правило умеет подсвечивать синтаксис, чтоб еще и визуально отличать одно от другого.
Доставка, в конечном счете, упирается в конкретных операторов сетей и инфраструктуру. Сомневаюсь, что кому-то под силу реально гарантировать хотя бы факт доставки на уровне сервиса ))
Daniel Sunrise: Всегда пожалуйста :) Хотел только добавить по поводу "востребованности" языков и "плана" вообще... расстаньтесь с мыслью, что может быть некий линейный план, мол, "если сначала то, а потом это, то потом автоматически профит". Дело не в том, чтоб накопить некое необходимое количество знаний по "правильным предметам", а в том, чтоб научиться выстраивать и расширять собственную систему знаний. Знания, не связанные между собой полезностью для решения какой-то проблемы, практически бессмысленны и, что называется, в одно ухо влетают, из другого вылетают. Если Вы, например, не будете знать, что такое грамматика или какими способами можно траверсировать дерево, то никогда до конца не поймете, как работает компилятор. С другой стороны, если Вы никогда в глаза не видели компилятор, не пытались отловить баг или понять, почему компилятор выдает какую-нибудь "странную" ошибку, у Вас просто не будет мотивации для понимания грамматик или деревьев. Но даже если у Вас будет глубочайшее понимание устройства компиляторов с 257 разных языков программирования, это никак не поможет Вам написать простейшее плавное изменение яркости светодиода на Ардуине, если Вы при этом не будете понимать, почему чувствительность человеческого зрения к интенсивности источника света логарифмическая, а не линейная.
Таким образом, "правильный план" у каждого свой и предельно прост: определитесь для себя лично, что именно является мотивацией для изучения чего-то нового, и всегда следуйте за этой мотивацией и учите именно то, чего прямо сейчас недостает для более глубокого понимания того, что делаете. Все остальное будет скучной и совершенно бесполезной зубрежкой. Если программировать железо прямо сейчас интересно, купите подходящую железяку и программируйте хоть на плюсах, хоть на ассемблере... надоест - купите FPGA и программируйте хоть на VHDL, хоть на Verilog. Захотите уйти в Веб или геймдев - вперед! Чтение книжек и лекции в универе могут либо помочь, либо пройти мимо, но они никак не смогут это заменить ;)
Просто так "внезапно" - нет, не могут. Если кажется, что поток спит без видимых причин, то есть только два варианта: либо он ушел в нативный код (и там колбасится - спит - ждет I/O...), либо системный шедулер перестал выделять всей JVM время. Второе бывает под виртуализатором... в целом JVM старается максимально честно раздавать потокам имеющееся время. Однако, чем гадать на кофейной гуще, лучше просто посмотреть, чем конкретно заняты подозрительные потоки... теми же jstack или jconsole :)
Вообще-то он попахивает не идиотизмом, а идиотизмом в квадрате: по виду это типичная заплатка на непонятный косяк в чужом коде или на собственное неправильное использование этого кода в других местах, с которыми просто было лень разбираться :)
