![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Special Enterprise Programming Olympics
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
theiced и skif_by и artureg решили устроить соревнование на тему "какой язык программирования более адекватен в руках профессионала" и попросили придумать им задание. Поскольку синтетические задания с результатом в виде консольных утилит это скучно, а они все умеют веб хорошо, я им придумал задачку с не сильно сложным веб-приложением. Условие под катом:Special Enterprise Programming Olympics
Problem 1:
You need to implement universal web-based application for report generation.
Application consists of:
* Database. You can use any relational DBMS you like, but you should have in mind ease of linux deployment.
* Web application deployed to your favorite web-server, app-server, whatever.
* Client-side JavaScript application working in modern browsers (>=IE7,Firefox>=5,Chrome)
* Web application must have report configuration file which contains:
** Unique system report id. Any string
** User-friendly name of report. For report titles and page headers.
** SQL query for report generation. SQL query is arbitrary and should contain parameters. SQL query will be in native format of used RDBMS.
** Query parameter description list.
Each parameter description contains parameter name, user-friendly caption,type,
output format and default value.
If you can infer parameter list from SQL query then this information is optional and
parameter list can be generated automatically.
** Query result field list. Field description should contain name, user-friendly name,
visibility flag(visible/not visible) and output format.
Field descriptions are optional - without description report should contain field
with default(returned from query) name and default output format.
* Types allowed for query parameters: integer,double,date,datetime,string,bool,decimal (money)
* Default values allowed for date or datetime parameters:
** Culture-invariant (!) string representation of any date or datetime
** If default value is prefixed with “@” then default parameter value is calculated as follows:
** @now - today (date) or current time(datetime)
** @prevmonthbeg - beginning of previous month
** @prevmonthend - end of previous month. Beware of difference in date and datetime (last day of month is 30/31, but last datetime of month is <00:00:00 01-of-nextmonth)
** @currmonthbeg - beginning of current month
** @currmonthend - end of current month
** @prevyearbeg - beginning of previous year
** @prevyearend - end of previous year
** @curryearbeg - beginning of current year
** @curryearend - end of current year
* Report configuration file will be edited once in a while based on
customers (report end-user) requirements.
Errors in configuration file format or in queries should be processed with
displaying of user-friendly error messages in client application and
error logging on server.
* Client application must show report list in any usable way(list of links, menu, tree, etc)
* Click on report must open report page which consists of:
** Report header (user-friendly report name)
** Report parameters table with user-friendly labels and editable parameters.
** "Refresh Report" button
** Report result table which is populated after click on "Refresh Report" button
or after Enter key press in any of parameter's edit controls.
* Paging or lazy result loading is not usually needed - most reports contains no more than 5 pages of data.
* When printing, report should follow the same structure as page, except for "Refresh" button.
* Report data is desirable to return in json or xml format, so it will be possible to
use wget/curl/any http client application to connect to server and get report data.
* Problem solution must contain:
** Deployment package for linux (any distro you like, but Ubuntu 10.04 LTS is preferred ). Also any deployment/configuration management system can be used.
** Deployment instructions.
Configuration file example: http://www.cacodaemon.org/content/so/ReportConfig.xml
Времени им - вообще до понедельника, но я бы добавил еще несколько дней на доработки по результатам.
no subject
no subject
С точки зрения юзера - это такой же отчет, как и другие, ничего волшебного. Единственная магия - флешку с базами конкретного филиала за конкретный период вставить, иначе никакого фокуса не получится. Флешки у главбуха, выдаются только по делу. Это вам не огороды городить с правами доступа к общей свалке.
no subject
Я понимаю, конечно, гордость за изобретение "супербазы" на флешке, но пора бы уже из детсадовских штанишек вырастать.
no subject
На периферийных базах ведется учет всех оттенков серого. А в "чистовые" базы из периферии заливаются только "правильные" документы. Лично я это называю консолидацией.
В случае формирования отчетов, некоторые отчеты формировались в "нативном" формате каждой базы, с учетом местной специфики. "Агрегировать" их в принципе невозможно, да и не нужно.
А прочие аналитические отчеты выдергивали данные во временную таблицу, затем эта таблица группировалась и сортировалась, и выводилась в кошерном формате
no subject
no subject
Ошибаетесь, по-крайней мере у меня этим занимаются обычные инженеры по обслуживанию информационной системы.
no subject
У меня с настройкой отчетов приходящие студенты-сисадмины вполне справляются.
no subject