Игорь Касперский: Естественно, это же на C#! Синтаксис VB.NET я наизусть не помню, это УГ.
Если вы уже знаете, что такое i++, то давно пора либо на C# перейти, либо уж научиться переводить код на C# на свой бейсик, и делать это каждый день по стопицот раз, раз вам так это нравится.
> Используют ли CMS, и если да, то как? По выбору клиента?
Если пока еще нету своего самописного фреймворка и своей CMS на его основе - то стоит делать по выбору клиента, и прежде всего по бюджету.
Ибо раз нету, значит либо юзать готовое, либо в рамках данного проекта придется разработать, и это R&D должно оплачиваться.
> Как организовывается штат, если скажем в команде php программисты, а клиент хочет бэкэнд на ruby/python, итп?
Вообще-то нормальный программист (если он программист, а не дизайнер), должен уметь пользоваться неограниченным кол-вом языков.
А если он и так ограничил себя тем, что отказался от фронт-енда и пишет только бек-енд, то тем более языков и пр. инструментов должен больше знать.
ВотЪ.
Вообще-то для Microsoft .NET с его довольно строгими и высокими стандартами по архитектуре правильнее был бы как раз вариант передавать ProcessStartInfo как свойство класса Process.
Microsoft .NET - это когда так:
frmAbout.Height = 500;
А не так:
FormSizer.SetHeight(frmAbout, 500);
И уж тем более не так:
var height = new NahuiNeNuzhniyOtdelniyClass(500);
frmAbout.SetHeight(height);
Два последних варианта - это скорее жаба или еще что-то линуксячее, но не Microsoft.NET.
Напрашивается вопрос: интересно, а когда так называемый "самый лучший программист" пишет какие-то свои классы для чего-то, то он там тоже разводит такую же линуксятину с архитектурой? И за счет чего же он тогда "лучший", если точно такой же пиздец наблюдается в 99,(9)% всех проектов, которые пишутся всякими мудадилетантами?
darkmayers: > Он указывается относительно утилиты.
А как она узнает, где она лежит? Точно ли не путает этот путь с рабочей папкой?
Вообще, очевидно, нужно отлаживать и экспериментировать. В частности - попробовать то же самое сделать через ярлык, задав неправильную рабочую папку в его свойствах.
И т.д.
Еще вот этот путь
process.StartInfo.FileName = OurFields.keskullPass + @"\Extractor.Deploy\Extractor.
Он точно верный, без лишних слешей? Это надо мессейджбоксом дебажить.
Борис Животное: > а Java идеальнее, чем .NET?
С чего бы столь странный вывод?
Если мыслить логически, то кроссплатформенное должно бы быть гораздо убожее, чем некроссплатформенное. Ибо хуже заточено под конкретную ОС.
А так как кроссплатформенность - это обычно Win-Linux, а Linux сильно отстает от Windows по функционалу, то в кроссплатформенном фреймворке часто просто "обрубают" специфический виндовый функционал (чтобы было совместимо с линуксом), вместо того, чтобы этот функционал реализовать для линукса (что стоило бы слишком много труда).
И, что самое печальное, зачастую авторы кроссплатформенного - сами - убежденные линуксоиды, поэтому они не просто не могут реализовать виндовый функционал на линуксе, но и не хотят, т.к. считают, что он там и не нужен. А это далеко не так.
Конечно же, Java на винде сложно тягаться даже с Delphi, а уж с .NET и подавно.
> а Xamarin?
Xamarin - УГ, еще и платное. По крайней мере, для Android лучше Java, что неудивительно, т.к. это официальный язык под ту ОС.
Кривые, сырые, малоизвестные мутанты вроде Mono/Xamarin или IronPython (когда под некую платформу пихают то, что под нее изначально не предназначалось) имеют смысл только при портировании готового кода на данном ЯП (если на андроиде надо юзать .NETовскую библиотеку и 80% требуемого функционала завязано на ней)
kuzia_bRatok: А ведь визарды - реально вещь полезная...
Скажем, в Qt они есть из коробки. Возможно, стоило бы и для .NET самому написать их такими, чтобы в дальнейшем можно было их клепать в пару кликов (например, сделать шаблоны элементов проекта для IDE Visual Studio, а может и плагин для IDE)
Вообще, раз уж говорим об архитектуре, то не могу не заметить, что .NET вообще очень далеко до идеала, очень многое в нем не идеально или просто отстутствует, так что стоит пилить самому. Даже такой простой класс, как MessageBox, можно сделать более совершенным, всего за полчаса времени (написав для него свою высокоуровневую обертку), однако MS, увы, этого так и не сделал за 13 лет.
Впрочем, .NET и винда еще цветочки. Вот на андроиде - реальная жесть, все приложения пишут под API ОС, все равно как под WinAPI на винде, это сущий кошмар любого разработчика, хоть раз писавшего под винду. Но, увы, воз и ныне там - высокоуровневых оберток как не было, так толком и нет.
> А по поводу Визардов, это я к примеру))
Правило "изучи аналоги, а потом пили свое" применимо и к чему угодно иному.
OnYourLips: > почему у тех, кто предпочитает низкий уровень, такое раздутой самомнение?
Потому что если использовать низкий уровень по назначению (писать драйвера, компиляторы, вскрывать протоколы и алгоритмы), то это реально тяжело.
Приведу аналогию. Стрелять из автомата Калашникова по врагу - это считается круто. А забивать им гвозди, которые можно также забить и молотком, это ипануто.
А в моем случае, всё и того круче.
Я предпочитаю высокий уровень, а не низкий. Понимаю, что такое удобство, абстракция. Более того, я создаю решения, которые по сути являются не просто высокоуровневыми, а сверхвысокоуровневыми (ибо они оборачивают и без того высокоуровневые библиотеки и фреймворки).
Но я обладаю полноценно глубокими знаниями, и также умею и средний уровень, и низкий, в тех случаях, когда это нужно.
Вот я вроде немало повидал разных программных продуктов, специально проводил для себя мини-исследования, и я не могу назвать еще одного такого же специалиста, как я, чтобы сразу все уровни в одном флаконе.
> (для меня)
Никто не против того, что вы выбрали только высокий уровень. Дело ваше.
Но в таком случае не нужно рассуждать о глубоких знаниях.
OnYourLips: > Путь до сеньора занимает около 10000 часов.
10000 часов поедания хот-догов - нормально?
> Используемые технологии.
И причем здесь глубина?
Наоборот, если вы используете готовые технологии, то вы абстрагиуетесь от низов.
Все у вас шиворот-навыворот.
> Это вам не в дизасемблере ковыряться.
Ну, для начала слово дизассемблер не помешало бы верно научиться писать.
Тем более, синьору, который на своей должности должен соображать, почему метод класса нужно называть ToString, а не ToCtring и не TOString, хотя и так и так все работает.
Ну и что в ваших Web-стартапах такого суперглубокого?
Может, вы вскрыли протокол Skype или Viber, написали для него отличную библиотеку и продаете ее разрабам?
Или что?
Но при чем здесь я?
При том, что вы рассуждаете о глубине познаний.
Это примерно как обычный стоматолог будет рассуждать о нейрохирургии.
OnYourLips: > C# чаще всего примменяется в ASP.NET.
Но это не мешает ему крайне широко применяться на десктопе под виндой.
> И в разработке мобильных игр.
Игры - это вообще другое направление. Там всё не так, как в прикладных приложениях, и не так, как в вебе.
И C# там тоже не тот, в том смысле, что под совсем другую платформу (например, Unity).
> профессионального программиста отличает глубина знаний в определенных областях.
Не может быть глубины познаний без достаточной ширины познаний. А ширина - как раз способствует глубине, а не наоборот. Пример: у меня язык не поворачивается сказать, что я изучил низкоуровневый протокол TCP, пока я работал только с ним самим да с одним протоколом на его основе - HTTP. Ибо если меня попросят отправить сырой пакет, но не в HTTP, а в соответствии с другим высокоуровневым протоколом (т.е. в ином формате) - а в реальной разработке обычно именно так и бывает! - то я обнаружу, что нихрена я не могу это сделать. Поработав же со всеми популярными протоколами на основе TCP, я могу отправить пакет в любом из этих "форматов", и даже разработать свой "формат".
Болтать про какого-то сферического "профессионального программиста" в вакууме можно сколько угодно, вот ответьте мне в двух словах - в чем проявляется ВАША глубина познаний?
Моя - в умении пользоваться дизассемблером, HEX-редактором (машинный код и другие бинарные форматы), и еще глубже, в умении составлять электронные логические схемы и вообще работать с железом.
Я лично имел только фен, как раз ELEMENT 858, и скажу, что толку от одного лишь фена очень мало. Во всяком случае, из многослойной платы с бессвинцовым припоем (как материнки в ноутбуках) ничего им так просто не выпаять, либо хреначить градусов 400-450 и испортить площадки и само выпаиваемое, либо просто не возьмет.
Нужен паяльник, и не простой паяльник, а с керамическим (а не нихромовым) нагр. элементом, нормальном жалом и т.д., ну и мощный достаточно. Такие паяльники - как раз в паяльных станциях, а не китайский ширпотреб за 300 руб, который втыкается тупо в розетку.
Таким паяльником уже можно разбавить места пайки сплавом Розе и выпаять деталь при более низкой температуре.
Но хорошо бы еще и ИК-подогрев снизу.
Илья Панков: > В любом случае под каждую задачу выбирать разный язык я смысла не вижу.
Ну, если все задачи одинаковые, то, конечно, это не нужно.
> А на чем обычно пишите Вы?
Вебом мало занимаюсь. На чем заказывают, на том и пишу. А заказывают... на всём. Фриланс же.
В своем собственном стартапе планирую пойти по хардкору: изучить все имеющиеся CMS, бекенд- и CSS-фреймворки, препроцессоры и кучу всего еще, и создать свой фреймворк (содержащий как клиентские, так и серверные средства), на его базе свою CMS, а на ее базе уже свой проект.
Это тяжело, долго, требует реального опыта, навыков архитектора, реверс-инженера и много кого еще, но зато в итоге мы получим не только проект с превосходной архитектурой и качеством кода, но еще и ре-юзабельные фреймворк и CMS, которые сами по себе годятся за отдельные проекты.
Нужно учиться программировать.
"Полезное" и "универсальное" - отчасти исключают друг друга. Что качественное, высокоуровневое, то обычно не универсальное, а заточенное под 1 определенную платформу. Например, разработчику под винду обязательно нужен C#.
Матан с Кнутом - вещь уж явно не универсальная, а наоборот, узкоспециальная. Как и вообще алгоритмически сложные решения. Все это применяется очень мало где и вполне может изучаться по мере появления таких задач, если они вообще когда-либо появятся.
Если вы уже знаете, что такое i++, то давно пора либо на C# перейти, либо уж научиться переводить код на C# на свой бейсик, и делать это каждый день по стопицот раз, раз вам так это нравится.