Подскажите на чем лучше писать программу
Играем в телепатов. Java подойдет?
Я не программист, поэтому спрашивайте нормально. Я понимаю, что можно написать данную программу на чем угодно. Вопрос про оптимальное решение!
А какие размеры логов/число коммутаторов?
А то по постановке мне кажется, что на вменяемых данных на современном компе подобная прогамма тормозить не должна.
А вообще подобную байду можно на перле например написать за небольшое время.
А то по постановке мне кажется, что на вменяемых данных на современном компе подобная прогамма тормозить не должна.
А вообще подобную байду можно на перле например написать за небольшое время.
Судя по описанию ничего сложного тут нет и использовать можно много разных языков. Может лучше выбирать не язык, а человека, который это сделает? И если ты не программист, то почему ты выбираешь язык?
Я не программистА зачем тогда спрашивать «на чем писать»? Что принципиально нового внесет в решение вопроса данное знание, если не секрет?
Размер файлов от 10 до 20 мб.
Спрашиваю на чем писать, потому что нашелся еще один программист и он хочет снова писать на аксессе, аргументируя тем, что это наилочший вариант для работы с базой данных. Хотелось бы здесь услышать явные минусы того, чтобы писать на акксесе и плюсы другого языка.
Вот пример файла:
http://rapidshare.com/files/420130058/MTS_MOS_MSC5_SWDATA.TX...
Там внизу есть файлы типа: это и есть названия патчей. Но каждое это название патчей входят в состав одного из патчсета. Т.е. в базе есть патчсет например:
PM.MRU56.K02.P111
в нем патчи:
APSLMY00.FI874L2Z.0001.0
APSLMY00.FU393L2Z.0001.0
APSLMY00.GC256L2Z.0001.0
APSLMY00.GE275L2Z.0001.0
APSLMY00.GF475L2Z.0001.0
APSLMY00.GF513L2Z.0004.0
APSLMY00.GG125L2Z.0001.0
Т.е. обработка огромного количества текста, поиск и выделение..
Спрашиваю на чем писать, потому что нашелся еще один программист и он хочет снова писать на аксессе, аргументируя тем, что это наилочший вариант для работы с базой данных. Хотелось бы здесь услышать явные минусы того, чтобы писать на акксесе и плюсы другого языка.
Вот пример файла:
http://rapidshare.com/files/420130058/MTS_MOS_MSC5_SWDATA.TX...
Там внизу есть файлы типа: это и есть названия патчей. Но каждое это название патчей входят в состав одного из патчсета. Т.е. в базе есть патчсет например:
PM.MRU56.K02.P111
в нем патчи:
APSLMY00.FI874L2Z.0001.0
APSLMY00.FU393L2Z.0001.0
APSLMY00.GC256L2Z.0001.0
APSLMY00.GE275L2Z.0001.0
APSLMY00.GF475L2Z.0001.0
APSLMY00.GF513L2Z.0004.0
APSLMY00.GG125L2Z.0001.0
Т.е. обработка огромного количества текста, поиск и выделение..
Есть файл ТХТ с логами от коммутаторов.В этом месте в сознании должно всплывать слово «Perl», а никак не java.
perl not dead
услышать явные минусы того, чтобы писать на акксесеединственный явный минус аксес в этой задаче, то что он будет жутко тормозить в плане закачки инфы из текстовых файлов.
>он хочет снова писать на аксессе,
access точно нафиг. он уже больше не поддерживается.
если будут предлагать дельфи, тоже нафиг, он тоже уже умер.
реальных варианта три:
1. mysql + php. это самый дешевый вариант, основная проблема найти вменяемых php-шников.
2. ms sql express + asp.net. запасной вариант, если требуется сложная серверная обработка. пока похоже, что у вас простая задача.
3. ms sql express+ wpf/winforms. запасной вариант, если требуется большой и сложный интерфейс. но по текущему описанию - интерфейс у вас похоже простой.
зы
тут что-то говорили про перл, его тем более нафиг.
перл хорош если нужно самому что-то поделать, но плох для разработки программ для других.
access точно нафиг. он уже больше не поддерживается.
если будут предлагать дельфи, тоже нафиг, он тоже уже умер.
реальных варианта три:
1. mysql + php. это самый дешевый вариант, основная проблема найти вменяемых php-шников.
2. ms sql express + asp.net. запасной вариант, если требуется сложная серверная обработка. пока похоже, что у вас простая задача.
3. ms sql express+ wpf/winforms. запасной вариант, если требуется большой и сложный интерфейс. но по текущему описанию - интерфейс у вас похоже простой.
зы
тут что-то говорили про перл, его тем более нафиг.
перл хорош если нужно самому что-то поделать, но плох для разработки программ для других.
тут что-то говорили про перл, его тем более нафиг.Это ещё почему? Совсем бездоказательно.
перл хорош если нужно самому что-то поделать, но плох для разработки программ для других.
Тем более в такой задаче вообще не видно смысла в использовании каких-то баз данных. Данная задача решается чуть более чем элементарно на Perl и других подобных языках. И поэтому даже если пытаться обвинять Perl в его "непонятности" или ещё в чём-то, то тут просто столько кода не будет, который может стать непонятным.
пользователи с программой будет как взаимодействовать? через командную строку?
данные где будут храниться? в сетевой папке - открытой всем на чтение и запись?
данные где будут храниться? в сетевой папке - открытой всем на чтение и запись?
пользователи с программой будет как взаимодействовать? через командную строку?Не всем программам гуй нужен.
данные где будут храниться? в сетевой папке - открытой всем на чтение и запись?Ты какие-то другие задачи уже пытаешься решить. Ты бы сказал, что она ещё заодно должна бизнес-процессы предприятия автоматизировать.
Скорее всего то, как это происходит у них сейчас более неудобно, нежели будет с командной стокой и парой шел-скриптов.
>нежели будет с командной стокой и парой шел-скриптов.
у непрофессионалов при использовании командной строки возрастает время вспоминания что именно надо ввести, и кол-во ошибок.
зы
командная строка (совместно с suggestions/intellisense) хороша для профессионалов.
у непрофессионалов при использовании командной строки возрастает время вспоминания что именно надо ввести, и кол-во ошибок.
зы
командная строка (совместно с suggestions/intellisense) хороша для профессионалов.
>В базу забивается информация что на каком коммутаторе должно стоять.
одной базой пользуется один человек или несколько?
одной базой пользуется один человек или несколько?
для ввода данных возможно юзать банальный ексель
а потом нажимать ярлык, которые выведет в черном окошке, что у вас в 110-ой строчке excel-я была ошибка?
как вариант, он может открывать тот же ексельный файл в котором ошибочные строчки будут уже покрашены.
Но вообще можно сделать и минисайт. Даже без всякого там мускула - какое нить примитивное хранилище взять для такой задачи. Хоть в файлах хранить данные. Если чутку заморочится с локами, то будет ок и совместная работа.
Но вообще можно сделать и минисайт. Даже без всякого там мускула - какое нить примитивное хранилище взять для такой задачи. Хоть в файлах хранить данные. Если чутку заморочится с локами, то будет ок и совместная работа.
программы должны быть интерактивными, чем быстрее программа реагирует на ввод пользователя, тем лучше (взять хотя бы instant search от гугла).
командная строка мало интерактивна, она больше заточена на пакетный режим.
командная строка обретает интерактивность только в руках профессионала при решении нештатных задач.
на рутинных задачах, требующих ввода от пользователя, gui предоставляет на несколько порядков больше удобства(интерактивности).
командная строка мало интерактивна, она больше заточена на пакетный режим.
командная строка обретает интерактивность только в руках профессионала при решении нештатных задач.
на рутинных задачах, требующих ввода от пользователя, gui предоставляет на несколько порядков больше удобства(интерактивности).
на рутинных задачах, требующих ввода от пользователя, gui предоставляет на несколько порядков больше удобства(интерактивности).
в теории именно так, но обычно кривоватый гуи, созданный руками программиста может тока добавлять проблем юзеру, хотя выглядеть будет не так страшно(для юзера) как командная строка.
Чтобы теорию приблизить к практике должен поработать спец по юзабилити и дизайну, но мы явно не тот случай рассматриваем
> Даже без всякого там мускула - какое нить примитивное хранилище взять для такой задачи. Хоть в файлах хранить данные. Если чутку заморочится с локами, то будет ок и совместная работа.
можно много чего придумать, и можно много всяких велосипедов поизобретать.
но на таких задачах лучше брать что-нибудь готовое широко-распространенное, на сопровождении это несколько раз окупится.
зы
на всяких случай напомню, что стоимость сопровождения обычно обходится дороже, чем разработка.
можно много чего придумать, и можно много всяких велосипедов поизобретать.
но на таких задачах лучше брать что-нибудь готовое широко-распространенное, на сопровождении это несколько раз окупится.
зы
на всяких случай напомню, что стоимость сопровождения обычно обходится дороже, чем разработка.
>Чтобы теорию приблизить к практике должен поработать спец по юзабилити и дизайну, но мы явно не тот случай рассматриваем
тогда честнее сравнивать кривой гуи с кривой командной строкой.
кривая командная строка - это будет нечто..
зы
под "кривой" в данном случае понимается вариант, когда программист не думает об удобстве пользователя.
тогда честнее сравнивать кривой гуи с кривой командной строкой.
кривая командная строка - это будет нечто..
зы
под "кривой" в данном случае понимается вариант, когда программист не думает об удобстве пользователя.
у непрофессионалов при использовании командной строки возрастает время вспоминания что именно надо ввести, и кол-во ошибок.Да ну не обязательно же заставлять их команду вручную вводить. Какой-нибудь ярлык сделать и всё.
зыКто такие эти профессионалы? В чём?
командная строка (совместно с suggestions/intellisense) хороша для профессионалов.
Любой кто там работает, по определению профессионал, т.к. это его профессия.
В общем не понимаю что ты хотел сказать.
Простого юзера обучить работать с простой программкой будет пофигу cmd это или gui с одной кнопкой. Бухи вон как-то с 1С работают, хотя на мой взгляд туда ламера подпускать это как обезьяне гранату дать. Но ничего, обучаются и умудряются ничего не ломать. На самом деле про 1С я почти ничего не знаю, но то что видел со стороны у меня сложилось впечатление, что это вполне легко поломать сделав что-нибудь не так.
И ещё раз повторюсь, в программе такой сложности глюбоко насрать на чём её писать. Т.е. здесь вообще неприменимы соображения типа "а вдруг нам понадобится гуй, поэтому будем писать на c#, а не на perl, хоть будет менее удобно" (все имена и названия в данном примере вымышлены, совпадения случайны
). Не применимы потому, что потом гораздо проще будет выкинуть это и написать заново на другом языке, чем думать что же в будущем нам понадобится.>Не применимы потому, что потом гораздо проще будет выкинуть это и написать заново на другом языке, чем думать что же в будущем нам понадобится.
если забыть про стоимость сопровождения, то да.
иначе получается:
принимаем решение: Zz - наше всё,
берем в штат(заключаем контракт) с Zz-разработчиком,
через два месяца выясняем, что Zz-ом часть задачи не покрывается,
принимаем решение: Yy - наше всё,
увольняем Zz-разработчика(разрываем контракт выплачивая неустойку в виде 2-5 окладов(это если для штата
срочно ищем разработчика под YY, платя деньги за срочность,
переписываем всё на YY.
ps
в реальности никакого перехода не будет, потому что где же этих новых разрабов взять, а будет попытка использовать инструмент Zz для решения несвойственных для него задач.
ззы
хорошо говорить: язык мы сменим по ходу, но на практике - это означает смену людей, подрядчиков и т.д.
если забыть про стоимость сопровождения, то да.
иначе получается:
принимаем решение: Zz - наше всё,
берем в штат(заключаем контракт) с Zz-разработчиком,
через два месяца выясняем, что Zz-ом часть задачи не покрывается,
принимаем решение: Yy - наше всё,
увольняем Zz-разработчика(разрываем контракт выплачивая неустойку в виде 2-5 окладов(это если для штата
срочно ищем разработчика под YY, платя деньги за срочность,
переписываем всё на YY.
ps
в реальности никакого перехода не будет, потому что где же этих новых разрабов взять, а будет попытка использовать инструмент Zz для решения несвойственных для него задач.
ззы
хорошо говорить: язык мы сменим по ходу, но на практике - это означает смену людей, подрядчиков и т.д.
хорошо говорить: язык мы сменим по ходу, но на практике - это означает смену людей, подрядчиков и т.д.Да чтоб тебя.
Я же и говорю, что в данном случае действительно пох. Там пару строк решение. Какое нафиг сопровождение? Нет, если это на C# с гуем и со всем как ты описываешь, то может и сопровождение понадобится и бабки придётся регулярно отстёгивать. А если аккуратно на Перле написать, то чего там сопровождать-то? В случае необходимости изменений ловится любой перлбыдлокодер (или какой другой который сделает всё что нужно.имхо:
командная строка — это средство, которое позволяет в одном экране объединить средства управления несколькими программами от разных разработчиков, в продвинутых случаях, ввод-вывод перенаправлять и т.п. Кроме того, позволяет легко работать через ssh, скажем.
Гуйи более системо-зависимы, и сложнее объединяются. Но, позволяют более удобное управление делать. В тех случаях, когда требуется управлять только одной программой (одним комплексом командная строка легко встраивается в гуй, просто делается окошко со строкой ввода, и всё, при этом добавляется куча дополнительный возможностей. Можно в качестве гуйя веб-морду использовать, тогда решаются и проблемы с доступом.
В описанной задаче лично я не вижу никакого преимущества командной строки перед веб-мордой. То есть, вообще никаких. А вот вебморда много плюсов имеет.
А вообще, пока не до конца понятно, какая функциональность от базы требуется, как забивается информация в базу, в первую очередь, насколько сложные там объекты и т.п. Пока мне кажется, что лучше всего будет связка что-нибудь вроде php + что-нибудь вроде mysql.
командная строка — это средство, которое позволяет в одном экране объединить средства управления несколькими программами от разных разработчиков, в продвинутых случаях, ввод-вывод перенаправлять и т.п. Кроме того, позволяет легко работать через ssh, скажем.
Гуйи более системо-зависимы, и сложнее объединяются. Но, позволяют более удобное управление делать. В тех случаях, когда требуется управлять только одной программой (одним комплексом командная строка легко встраивается в гуй, просто делается окошко со строкой ввода, и всё, при этом добавляется куча дополнительный возможностей. Можно в качестве гуйя веб-морду использовать, тогда решаются и проблемы с доступом.
В описанной задаче лично я не вижу никакого преимущества командной строки перед веб-мордой. То есть, вообще никаких. А вот вебморда много плюсов имеет.
А вообще, пока не до конца понятно, какая функциональность от базы требуется, как забивается информация в базу, в первую очередь, насколько сложные там объекты и т.п. Пока мне кажется, что лучше всего будет связка что-нибудь вроде php + что-нибудь вроде mysql.
В описанной задаче лично я не вижу никакого преимущества командной строки перед веб-мордой. То есть, вообще никаких. А вот вебморда много плюсов имеет.И какие же плюсы?
>И какие же плюсы?
1. доступ к данным из любой точки с любого оборудования
2. совместный доступ
3. безопасность (в том числе защита от дурака)
4. описание того, что надо делать совмещено с ui
1. доступ к данным из любой точки с любого оборудования
2. совместный доступ
3. безопасность (в том числе защита от дурака)
4. описание того, что надо делать совмещено с ui
возможность более наглядного отображения того, что есть. Есть куча разных устройств, видимо разного назначения. Графическое (хотя бы в виде цветных таблиц) отображение этих устройств, чего от каждого требуется (какие патчи иметь, скажем и чего реально есть. Удобный способ загрузки файлов, ну и вообще гибкость.
Как я понимаю, задача хитрее, чем кажется на первый взгляд:
===================
Требуемая программа - это база всех коммутаторов с информацией какие патчи должны стоять, а какие пропущенны (т.е. должны были поставяться по плану, но их в логах почему-то нет)
===================
скажем, где хранится информация о планах на патчи? Она разная для разных устройств? Если да, то как вводится, тупо дублируется для каждого устройства, или вводятся какие-то классы устройств?
В общем, у меня подозрение, что может там и очень примитивно всё сделано, но как только представится возможность, заказчики захотят большего и реальное ТЗ будет конкретно раздуваться.
Как я понимаю, задача хитрее, чем кажется на первый взгляд:
===================
Требуемая программа - это база всех коммутаторов с информацией какие патчи должны стоять, а какие пропущенны (т.е. должны были поставяться по плану, но их в логах почему-то нет)
===================
скажем, где хранится информация о планах на патчи? Она разная для разных устройств? Если да, то как вводится, тупо дублируется для каждого устройства, или вводятся какие-то классы устройств?
В общем, у меня подозрение, что может там и очень примитивно всё сделано, но как только представится возможность, заказчики захотят большего и реальное ТЗ будет конкретно раздуваться.
> 1. доступ к данным из любой точки с любого оборудования
> 2. совместный доступ
Ну необходимость этого ещё пока не ясна. Но в противовес же не-веб решение можно тоже запускать на любом компе, но при этом ещё и с персонализированными настройками, независимо от наличия сети, нет единой точки отказа и т.п.
> 3. безопасность (в том числе защита от дурака)
сомнительно (не вижу явных угроз от командной строки)
> 4. описание того, что надо делать совмещено с ui
нет необходимости для простых действий
> 2. совместный доступ
Ну необходимость этого ещё пока не ясна. Но в противовес же не-веб решение можно тоже запускать на любом компе, но при этом ещё и с персонализированными настройками, независимо от наличия сети, нет единой точки отказа и т.п.
> 3. безопасность (в том числе защита от дурака)
сомнительно (не вижу явных угроз от командной строки)
> 4. описание того, что надо делать совмещено с ui
нет необходимости для простых действий
возможность более наглядного отображения того, что естьНу как бы консольной программе ничто не мешает на выходе генерить тот же html-отчёт.
>сомнительно (не вижу явных угроз от командной строки)
как минимум легко запороть(грохнуть) данные, которые подвергаются модификации
как минимум легко запороть(грохнуть) данные, которые подвергаются модификации
как минимум легко запороть(грохнуть) данные, которые подвергаются модификацииА откуда логи изначально берутся. Я думаю, что с таким же успехом их можно грохнуть при копировании на веб-сервер. В общем тут угрозы сильно туманные, т.к. не ясно откуда данные берутся, как обрабатываются и т.п.
Ну как бы консольной программе ничто не мешает на выходе генерить тот же html-отчёт.Я пока пытаюсь представить, как всё должно выглядеть.
Вот есть у нас на сервере программа (хотят ведь на отдельном компьютере). Я, допустим, открываю какой-нибудь putty, захожу на сервер.
1) как мне загрузить текстовый файл с обновлениями?
2) сделала программа какой-нибудь html отчёт. Значит, я должен его как-то скачать к себе на компьютер, или запускать браузер, дабы его с сервера посмотреть. Не говоря уж о какой-то интерактивности.
Вообще, если уж на то пошло, то мне кажется, что и на локальном компьютере часто было бы разумным устанавливать какой-нибудь апач и делать приложение с веб-интерфейсом, даже в тех случаях, когда сеть и не требуется. Не всегда, но это часто это довольно хорошая альтернатива командным строками или обычным гуйям.
составьте сценарии использования
Они хотят отдельный сервер, т.к. у них тормозит. На самом деле тормозить похоже нечему, так что отдельный сервер не нужен.
программист и он хочет снова писать на аксессе, аргументируя тем, что это наилочший вариант для работы с базой данных.по делу.
Это не програмист, а мракобес. Гоните его в шею.
Аксесс - наихудший вариант работы с БД. Аргументы:
тормознутость
Совершенно дикий диалект скл(нечитаемый).
Невозможноссть(крайняя геморность) работы с системами контроля версий
В случае использования ВБА как языка решения задачи - устаревший, невыразительный язык и нестабильный рантайм.
Аксесс - наихудший вариант работы с БД. Аргументы:зато прогеру данную задачу можно за несколько часов написать, и оно будет работать
оно не_будет работать. Оно будет делать вид. Чего спорить, уже один прогер им написал, так работает, что приходится теперь переписывать плевую задачу. Это не единичный случай, уж поверь мне, видел таких "работающих задач" немало.
прогер прогеру рознь, работать будет, ничего сверхестественного в задаче нет, я на аксессе писал подобную вещь, ну тормозит немножко, зато работает.
и чего? Я не одну подобную и не только подобную вещь писал, а еще больше разгребал после таких вот песателей вещей.
Зачем делать говно, если можно сделать сразу нормальную вещь причем с меньшими трудозатратами. Да, нужно знаний конечно чуть побольше, чем после прочтения книжки "Аксесс за 24 часа".
Зачем делать говно, если можно сделать сразу нормальную вещь причем с меньшими трудозатратами. Да, нужно знаний конечно чуть побольше, чем после прочтения книжки "Аксесс за 24 часа".
реальных варианта три:Читал всю тему до конца и плакал горькими слезами. , я понимаю, что ты крутой модератор и даже форумы на .NET пишешь и всё это круто и энтерпрайзно, но скажи, на каких языках, кроме .NET'овых, тебе доводилось писать? Я не к чему-нибудь в стиле «ты тупое ничего не смыслящее говно», а мне просто интересно, правда, писал ли ты или хотя бы видел не однострочники, а нормальный промышленный код на перле, с требованиями к стилю, комментариями и т.п.
1. mysql + php. это самый дешевый вариант, основная проблема найти вменяемых php-шников.
2. ms sql express + asp.net. запасной вариант, если требуется сложная серверная обработка. пока похоже, что у вас простая задача.
3. ms sql express+ wpf/winforms. запасной вариант, если требуется большой и сложный интерфейс. но по текущему описанию - интерфейс у вас похоже простой.
зы
тут что-то говорили про перл, его тем более нафиг.
перл хорош если нужно самому что-то поделать, но плох для разработки программ для других.
Я тебя уверяю, сопровождать его будет не сложнее, а во многом даже проще, чем веб-приложение на том же дот-нете.
Потому что:
1. Перловиков отнюдь не так мало, как хотелось бы тем, кто по форумам надсадно кричит «перл мертв!11».
2. В перл будет куда меньше проблем с расширением. В дотнете, например, придётся заранее закладываться на то, что ты делаешь веб-приложение. В перле подключение такой функциональности займёт всего несколько строчек. Никакой правки кучи конфигов, страшных настроек в web.config, развёртывания сборок, НИЧЕГО. Весь функционал легко и прозрачно описывается в коде. В самом простом случае достаточно пары строк кода и положить скрипт в cgi-bin апача. Либо к вашим услугам >9000 готовых модулей типа Starman позволят обойтись даже без апачей, иисов и прочих доп.серверов. Точно так же легко и непринужденно приделывается гуй. Tk, Qt — всё это в перле есть.
3. Основным требованием в ТЗ сейчас является собственно обработка логов, так как имеющийся софт говно, работает медленно и много жрёт. Будем сравнивать, кто будет работать быстрее и жрать меньше — дотнетовая сборка или код на языке, созданном для обработки логов?
причем с меньшими трудозатратами.извините, но хуй (стоимость аксесса канешна не берем
)не извиняю, ты недостаточно информирован вероятно.
Т.е. скажем так, если знать только о существовании аксесса и какого нить ентерпрайз решения, то в рамках таких знаний да.
Но вот в мире гораздо больше возможностей чем кажется.
Т.е. скажем так, если знать только о существовании аксесса и какого нить ентерпрайз решения, то в рамках таких знаний да.
Но вот в мире гораздо больше возможностей чем кажется.
Но вот в мире гораздо больше возможностей чем кажется.ты бери не коня в вакууме, а конкретную контору с конкретными специалистами.
Еслиб у них был такой гуру, который разбирается в технологиях, то они бы не спрашивали совета здесь, значит гуру у них нет.
И следовательно по твоей методологии при разработке им придется потратить еще денег и на него.
И следовательно по твоей методологии при разработке им придется потратить еще денег и на него.раз они спрашивают, то они имеют возможность выбора. Иначе б давно накорячили бы очередную говняшку. Для этой задачи не нужно быть гуру, я ж написал, надо просто знать чуть больше, чем написано в мелкососных книгах для чайников.
Гуру за такую задачу и браться не будет.
Гуру за такую задачу и браться не будет.видать вокруг один Гуру
раз они спрашивают, то они имеют возможность выбораскорее имеют Н-ную сумму
>Я тебя уверяю, сопровождать его будет не сложнее, а во многом даже проще, чем веб-приложение на том же дот-нете.
>Потому что:
пишешь все правильно, вот только ты забываешь, что если топик-стартер найдет perl-программиста, то это будет средне-хреновый perl-программист. на хорошего у него просто денег не хватит.
а код средне-хренового perl-программиста много хуже, чем средне-хреновой .net-код.
средне-хреновый php-код, имхо, будет лучше, чем средне-хреновый perl-код, просто за счет большего коммьюнити, а значит и большего обсасывания типичных граблей, и рекомендаций по их обходу.
>Потому что:
пишешь все правильно, вот только ты забываешь, что если топик-стартер найдет perl-программиста, то это будет средне-хреновый perl-программист. на хорошего у него просто денег не хватит.
а код средне-хренового perl-программиста много хуже, чем средне-хреновой .net-код.
средне-хреновый php-код, имхо, будет лучше, чем средне-хреновый perl-код, просто за счет большего коммьюнити, а значит и большего обсасывания типичных граблей, и рекомендаций по их обходу.
вот у ubuntu коммьюнити больше, чем у archlinux, а качество контента на форумах отличается в другую сторону.
а значит и большего обсасывания типичных граблей, и рекомендаций по их обходу.да, только мне, когда приходится ковырять чего-то на php, приходится искать в интернете, как написать в STDERR. можно, конечно, и такие грабли обсасывать
Они хотят отдельный серверкстати, если народ хочет отдельный сервер, рекомендую пролог - необходимость закупки быстрого железа замечательно доказыается с его помощью.
>качество контента на форумах отличается в другую сторону.
это нормально. на форумах нубы как раз и сидят. а у малораспространенных языков(платформ и т.д.) как раз нубов обычно и нет.
это нормально. на форумах нубы как раз и сидят. а у малораспространенных языков(платформ и т.д.) как раз нубов обычно и нет.
>прогер прогеру рознь, работать будет, ничего сверхестественного в задаче нет, я на аксессе писал подобную вещь, ну тормозит немножко, зато работает.
на access-е имело бы смысл писать, если бы топик-стартер access знал, и сам бы на нем писал.
access удобен, что там можно легко допилить прогу по ходу ее использования.
а если заказ идет на сторону, то этот плюс нивелируется, и остаются только минусы.
на access-е имело бы смысл писать, если бы топик-стартер access знал, и сам бы на нем писал.
access удобен, что там можно легко допилить прогу по ходу ее использования.
а если заказ идет на сторону, то этот плюс нивелируется, и остаются только минусы.
пишешь все правильно, вот только ты забываешь, что если топик-стартер найдет perl-программиста, то это будет средне-хреновый perl-программист. на хорошего у него просто денег не хватит.Так, давай перейдём от голого теоретизирования к практике. Сколько ты, как .NET-овый программист, потребуешь за решение данной задачи? Допустим, что хттп-фронтенд действительно включен в ТЗ.
а код средне-хренового perl-программиста много хуже, чем средне-хреновой .net-код.
>Так, давай перейдём от голого теоретизирования к практике. Сколько ты, как .NET-овый программист, потребуешь за решение данной задачи? Допустим, что хттп-фронтенд действительно включен в ТЗ.
я-то потребую тысяч 20 зелени, а вот ниже-средний .net-программист-студент выйдет тысяч на 20 рублей (без налогов).
я-то потребую тысяч 20 зелени, а вот ниже-средний .net-программист-студент выйдет тысяч на 20 рублей (без налогов).
Ага, то есть за 20 тыс. рублей на .NET мы найдем "ниже-среднего программиста-студента". Ты меня извини, конечно, но при таких расценках у .NET нету шансов. Потому что полноценный отлаженный парсер без веб-интерфейса для топикстартеровой задачи средненький программист-нестудент напишет на перле часов за 6.
Web-интерфейс с БД отладить (чтобы всё было именно что юзабельно, а не говноинтерфейс) еще примерно столько же. Это 12 часов чистого рабочего времени. Лично мне, будь я оным перл-программистом, больше 10крур потребовать за это не позволила бы совесть.
Web-интерфейс с БД отладить (чтобы всё было именно что юзабельно, а не говноинтерфейс) еще примерно столько же. Это 12 часов чистого рабочего времени. Лично мне, будь я оным перл-программистом, больше 10крур потребовать за это не позволила бы совесть.
Это 12 часов чистого рабочего времени.мне кажется, что это преуменьшение
Ну для совсем уж гарантии можно заложиться на два рабочих дня — 16 часов — но и то это для избыток на самом деле, я указывал больше времени, потому что знаю, что у меня бы, например, был тупняк на пару часов как раз с созданием гуя — не потому что я тупой, а потому что на UI меня всегда поначалу клинит, слишком редко делаю и слишком сильно это не люблю. Тот, кто такими вещами занимается чаще, сделает быстрее.
я-то потребую тысяч 20 зелениЯ полагаю в эту цифру включено не только профессиональное программирование, но и профессиональное проектирование, профессиональное тестирование, профессиональное тестирование на моделях и профессиональная верификация?
профессиональное проектирование, профессиональное тестирование, профессиональное тестирование на моделях и профессиональная верификация?а в 100000 оно будет включено?
На компьютере! 
Оставить комментарий
mikestat
В нашей компании 10 лет назад написал один из сотрудников такую программу на аксессе. Она очень медленная, комп виснет и проверяет все неправильно. Сейчас компания пришла к решению, что лучше заказать данный софт с нуля. Хотелось бы узнать у вас на чем лучше писать такую программу и возможно ли такое, что все процессы сравнивания проходили на удаленном компьютере (сервере) и потребляли его ресурсы.Краткое ТЗ по софту:
Есть файл ТХТ с логами от коммутаторов. Логи представлены в виде текста в файле. Данные логи показывают всю историю этого коммутатора, включая какие на нем сейчас стоят патчи.
Требуемая программа - это база всех коммутаторов с информацией какие патчи должны стоять, а какие пропущенны (т.е. должны были поставяться по плану, но их в логах почему-то нет).
Принцип программы:
В базу забивается информация что на каком коммутаторе должно стоять. Далее импортируем файл и программа сравнивает его содержимое с базой и говорит что есть, а чего нет.