success story: NTed
Locked
 
|
I think my last post of this message fell into the time the old mailing list dies. So here it is again
--- We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, …). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, …). The rehearsal should improve the coordination of several hospitals, firemen…as well as the quickest possible treatment for the injured. One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. Technically it is done in smalltalk solo. The server is a pharo image. It has - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data - a static file server that delivers static resources to client tablets - a websocket connector that is used by the clients to connect to the server - a http handler to export data to other analysis tools The client is done with amber smalltalk. It - loads the web page containing amber from the server - connects back to the server - downloads a UI spec for the injured using the tablet to display personalized UI elements - stores events on the tablet in case the injured is offline - measures times to instruct the injured If you have any questions please don't hesitate to ask. Norbert |
Re: success story: NTed
|
|
Great success story, Norbert, it is really good to hear it !
One request though: sexy screenshots ;-) Sven On 14 May 2013, at 11:37, Norbert Hartl <[hidden email]> wrote: > I think my last post of this message fell into the time the old mailing list dies. So here it is again > > --- > > We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, …). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, …). > The rehearsal should improve the coordination of several hospitals, firemen…as well as the quickest possible treatment for the injured. > > One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. > > Technically it is done in smalltalk solo. > > The server is a pharo image. It has > > - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data > - a static file server that delivers static resources to client tablets > - a websocket connector that is used by the clients to connect to the server > - a http handler to export data to other analysis tools > > The client is done with amber smalltalk. It > > - loads the web page containing amber from the server > - connects back to the server > - downloads a UI spec for the injured using the tablet to display personalized UI elements > - stores events on the tablet in case the injured is offline > - measures times to instruct the injured > > If you have any questions please don't hesitate to ask. > > Norbert -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org |
|
|
Good idea. I need to collect them first from mobile devices and other systems. Until then here are some of the admin interface (it's all in german)
    Norbert Am 14.05.2013 um 11:43 schrieb Sven Van Caekenberghe <[hidden email]>: Great success story, Norbert, it is really good to hear it ! |
|
|
In reply to this post by NorbertHartl
Sounds most excellent! I do have some questions:
1) What datastore is used, both on the server as well as tablet ? 2) What is the OS of the tablet? 3) How smooth was the Amber development? Can you do remote debugging on the server? 4) How did you manage to convince the ones paying for the project, that it would be done in Smalltalk?! -Paul |
Re: [Pharo-dev] success story: NTed
|
|
In reply to this post by NorbertHartl
I do have one question: what was your experience with Amber?
Nico On May 14, 2013, at 11:37 AM, Norbert Hartl <[hidden email]> wrote: > I think my last post of this message fell into the time the old mailing list dies. So here it is again > > --- > > We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, …). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, …). > The rehearsal should improve the coordination of several hospitals, firemen…as well as the quickest possible treatment for the injured. > > One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. > > Technically it is done in smalltalk solo. > > The server is a pharo image. It has > > - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data > - a static file server that delivers static resources to client tablets > - a websocket connector that is used by the clients to connect to the server > - a http handler to export data to other analysis tools > > The client is done with amber smalltalk. It > > - loads the web page containing amber from the server > - connects back to the server > - downloads a UI spec for the injured using the tablet to display personalized UI elements > - stores events on the tablet in case the injured is offline > - measures times to instruct the injured > > If you have any questions please don't hesitate to ask. > > Norbert -- Nicolas Petton http://www.nicolas-petton.fr |
|
|
In reply to this post by pdavidow
thanks,
Am 14.05.2013 um 15:09 schrieb Paul Davidowitz <[hidden email]>: > Sounds most excellent! I do have some questions: > 1) What datastore is used, both on the server as well as tablet ? On the server I save all the data with Fuel on disc, one file per rehearsal. The storage on the client is obviously localStorage. > 2) What is the OS of the tablet? It is android 4.3. The tablets we use are Google Nexus 7 Tablets. Main reason was that it is a modern device and has a low price. We have 26 tablets so the costs sum up quickly. > 3) How smooth was the Amber development? Can you do remote debugging on > the server? The development with amber was fine. You need to get used to the habbit of pressing a button to save your code. From then it is not as comfortable as developing in a pharo image but much better as developing javascript with a text editor. With the new IDE helios I think it gets even better to develop with amber. You know that you are again developing something smalltalkish if you see that there is no need for page reloading. There is a lot of potential that I didn't exploit by now. And soon the debugger will get stepping so this will be wonderful > 4) How did you manage to convince the ones paying for the project, that > it would be done in Smalltalk?! > I don't argue :) Ok, let me explain it. I think it is the wrong question. Better ask yourself what you are selling. If it is a software component that needs to be tightly coupled with your customer existing software then the technology and language are important. If you are selling a complete product or a service the language isn't that important. So if the language doesn't count what does? Right, time and money. If the most important thing is to get the software out for an acceptable price in a timely manner with good quality (mostly it is in exactly that order) then you need to choose the tool that enables you to do it that way. Don't think too much about what a customer might not like with your approach. You should just know why you decided to use your technology stack. And if they ask tell them why. My habit is not to talk about it until the customer wants to. And I can't remember when the last one wanted to know exactly what we are using. Norbert |
|
|
In reply to this post by pdavidow
Another question: Were any of the Magritte-generated forms ajaxafied,
and if so, how did it go? -Paul |
|
|
Do you know Reef?
Because this is a component library on top/inside seaside that is magritte based and fully ajaxified. > Another question: Were any of the Magritte-generated forms ajaxafied, > and if so, how did it go? > > -Paul > |
Re: [Pharo-dev] success story: NTed
|
|
In reply to this post by Nicolas Petton
Hi Nico,
> I do have one question: what was your experience with Amber? > as an overall statement I would say it was a pleasure to use amber to develop the app. The initial setup until the class browser opens is easy. Learning how to create packages and knowing that code persistence is based on packages is also quite ok because amber includes a WebDav Server that can be started from the downloaded amber repo. So no big problems in starting. Thinks that go less smooth: - the web app I'm developing is checked into git. Amber puts all files (js and st) in the same directory. This makes managing files in version control system a bit cumbersome. - all code is put in the same directory. The amber code checked out from the repository is in the same place as the code that I produced myself. Again you need to do additional steps to do to clean it up - tools for combining code are missing. That is not a big problem because a simple cat on the console can solve this but would be nice not have to. - I prepared two different locations on my web server for the same app. One that is used to develop (the WebDav server access it) and one where only the combined javascript source code is used. This is needed to test the target deployment. Something that could ease this would be wonderful What keeps me from using it in every project: - The startup times for amber can be quite huge. All the class initialization is a lot of stuff that burns CPU cycle. On an iphone you don't notice really but on the Nexus 7 tablet it takes 2-4 seconds for initialization and the first page to appear. This is a not a problem for desktop browsers but for mobile ones where I find amber extremely good for. I only used amber in pre pre 1.0 versions and I know there have been optimizations that I didn't test, yet. And the annoying "You didn't ask for but I add it anyway wishlist": - I need to test Helios because I think it solves a lot of issues with the current browser. I don't know how it is supposed to work that you have a second window with the IDE that accesses a page. But I'm sure it works flawlessly or I misunderstood it from the screenshots - retarget files on the disc. I would like to have different paths on disc for separate packages. - amber using websockets to connect to a backend pharo server. This can be used for comfortable code management, amber support for state transport client->server and server->client and to replicate console log to the pharo transcript (or whatever). This is important on mobile devices where sometimes you cannot access the browser console. - it would be fine to have support for obfuscation. It is not only for hiding code but also for making it smaller thus saving bandwidth and startup times. This could be the case if the produced javascript code would be work with google closure compiler. Even better would be to have visitor for AST/IR to make it even more effective/less dangerous. Norbert Am 14.05.2013 um 15:32 schrieb Nicolas Petton <[hidden email]>: > Nico > > > On May 14, 2013, at 11:37 AM, Norbert Hartl <[hidden email]> wrote: > >> I think my last post of this message fell into the time the old mailing list dies. So here it is again >> >> --- >> >> We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, …). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, …). >> The rehearsal should improve the coordination of several hospitals, firemen…as well as the quickest possible treatment for the injured. >> >> One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. >> >> Technically it is done in smalltalk solo. >> >> The server is a pharo image. It has >> >> - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data >> - a static file server that delivers static resources to client tablets >> - a websocket connector that is used by the clients to connect to the server >> - a http handler to export data to other analysis tools >> >> The client is done with amber smalltalk. It >> >> - loads the web page containing amber from the server >> - connects back to the server >> - downloads a UI spec for the injured using the tablet to display personalized UI elements >> - stores events on the tablet in case the injured is offline >> - measures times to instruct the injured >> >> If you have any questions please don't hesitate to ask. >> >> Norbert > > -- > Nicolas Petton > http://www.nicolas-petton.fr > > |
|
|
In reply to this post by pdavidow
Am 14.05.2013 um 17:08 schrieb Paul Davidowitz <[hidden email]>: > Another question: Were any of the Magritte-generated forms ajaxafied, > and if so, how did it go? > I used ajax only for the things where it is absolutely necessary. This is in forms where you have a select with some options and selecting something changes the the form. This is for example in the large screenshot. There you have a select box to choose the interaction scheme. Selecting it display the selected scheme and you can edit immediately. IMHO ajax is like most other technologies. If you don't have a good reason to use it then don't. Ajax is fine to make better dynamic UIs but at the same time it can make your web application very brittle. The scenario we have here is that there is a short way from browser to server. So loads go really quick and you can't tell it apart from an ajaxified application. So I decided to make not big use of AJAX. Norbert |
|
|
In reply to this post by stephane ducasse
Am 14.05.2013 um 17:14 schrieb stephane ducasse <[hidden email]>: > Do you know Reef? > Because this is a component library on top/inside seaside that is magritte based and fully ajaxified. > I know Reef only from Estebans presentations with and without beer. I never really looked into it. Maybe I should but not for this project. There is no need to make it more complex. But I didn't know it is magritte based. So I'll have a look with or without Esteban thanks for mentioning, Norbert >> Another question: Were any of the Magritte-generated forms ajaxafied, >> and if so, how did it go? >> >> -Paul >> > > |
Re: [Pharo-dev] success story: NTed
|
|
In reply to this post by NorbertHartl
Hi Norbert,
I'm answering inside your email. If you'd like more explanations about some of the points, please just tell me. I'm also forwarding to Amber ML. On May 14, 2013, at 5:37 PM, Norbert Hartl <[hidden email]> wrote: > Hi Nico, > >> I do have one question: what was your experience with Amber? >> > > as an overall statement I would say it was a pleasure to use amber to develop the app. The initial setup until the class browser opens is easy. Learning how to create packages and knowing that code persistence is based on packages is also quite ok because amber includes a WebDav Server that can be started from the downloaded amber repo. So no big problems in starting. > > Thinks that go less smooth: > > - the web app I'm developing is checked into git. Amber puts all files (js and st) in the same directory. This makes managing files in version control system a bit cumbersome. One approach that worked for me and others is to ignore the .js files and recompile the .st files of your project using a git hook when you pull. > - all code is put in the same directory. The amber code checked out from the repository is in the same place as the code that I produced myself. Again you need to do additional steps to do to clean it up You can now deal with that. loadAmber() takes additional optional arguments to deal with project paths. > - tools for combining code are missing. That is not a big problem because a simple cat on the console can solve this but would be nice not have to. bin/amberc does that. That's actually how the WebDAV of Amber is compiled into one file :) > - I prepared two different locations on my web server for the same app. One that is used to develop (the WebDav server access it) and one where only the combined javascript source code is used. This is needed to test the target deployment. Something that could ease this would be wonderful > > What keeps me from using it in every project: > > - The startup times for amber can be quite huge. All the class initialization is a lot of stuff that burns CPU cycle. On an iphone you don't notice really but on the Nexus 7 tablet it takes 2-4 seconds for initialization and the first page to appear. This is a not a problem for desktop browsers but for mobile ones where I find amber extremely good for. I only used amber in pre pre 1.0 versions and I know there have been optimizations that I didn't test, yet. The latest stable release of Amber should be *a lot* faster to load. > > And the annoying "You didn't ask for but I add it anyway wishlist": > > - I need to test Helios because I think it solves a lot of issues with the current browser. I don't know how it is supposed to work that you have a second window with the IDE that accesses a page. But I'm sure it works flawlessly or I misunderstood it from the screenshots yes, it does :) > - retarget files on the disc. I would like to have different paths on disc for separate packages. You can also do that now with loadAmber() > - amber using websockets to connect to a backend pharo server. This can be used for comfortable code management, amber support for state transport client->server and server->client and to replicate console log to the pharo transcript (or whatever). This is important on mobile devices where sometimes you cannot access the browser console. ok, that's an interesting point :) > - it would be fine to have support for obfuscation. It is not only for hiding code but also for making it smaller thus saving bandwidth and startup times. This could be the case if the produced javascript code would be work with google closure compiler. Even better would be to have visitor for AST/IR to make it even more effective/less dangerous. it does work with Google Closure Compiler, there's an option in bin/amberc too for that ;) > Cheers, Nico > Norbert > > Am 14.05.2013 um 15:32 schrieb Nicolas Petton <[hidden email]>: > >> Nico >> >> >> On May 14, 2013, at 11:37 AM, Norbert Hartl <[hidden email]> wrote: >> >>> I think my last post of this message fell into the time the old mailing list dies. So here it is again >>> >>> --- >>> >>> We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, …). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, …). >>> The rehearsal should improve the coordination of several hospitals, firemen…as well as the quickest possible treatment for the injured. >>> >>> One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. >>> >>> Technically it is done in smalltalk solo. >>> >>> The server is a pharo image. It has >>> >>> - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data >>> - a static file server that delivers static resources to client tablets >>> - a websocket connector that is used by the clients to connect to the server >>> - a http handler to export data to other analysis tools >>> >>> The client is done with amber smalltalk. It >>> >>> - loads the web page containing amber from the server >>> - connects back to the server >>> - downloads a UI spec for the injured using the tablet to display personalized UI elements >>> - stores events on the tablet in case the injured is offline >>> - measures times to instruct the injured >>> >>> If you have any questions please don't hesitate to ask. >>> >>> Norbert >> >> -- >> Nicolas Petton >> http://www.nicolas-petton.fr >> >> > > -- Nicolas Petton http://www.nicolas-petton.fr |
Re: [amber-lang] [Pharo-dev] success story: NTed
|
|
Nico,
thanks for your helpful input. I will try all of these when the project enters the next phase. Well, I will measure the startup times soon because it influences the do or don't of using it in new projects. Norbert Am 15.05.2013 um 12:12 schrieb Nicolas Petton <[hidden email]>: > Hi Norbert, > > I'm answering inside your email. If you'd like more explanations about some of the points, please just tell me. I'm also forwarding to Amber ML. > > On May 14, 2013, at 5:37 PM, Norbert Hartl <[hidden email]> wrote: > >> Hi Nico, >> >>> I do have one question: what was your experience with Amber? >>> >> >> as an overall statement I would say it was a pleasure to use amber to develop the app. The initial setup until the class browser opens is easy. Learning how to create packages and knowing that code persistence is based on packages is also quite ok because amber includes a WebDav Server that can be started from the downloaded amber repo. So no big problems in starting. >> >> Thinks that go less smooth: >> >> - the web app I'm developing is checked into git. Amber puts all files (js and st) in the same directory. This makes managing files in version control system a bit cumbersome. > > One approach that worked for me and others is to ignore the .js files and recompile the .st files of your project using a git hook when you pull. > > >> - all code is put in the same directory. The amber code checked out from the repository is in the same place as the code that I produced myself. Again you need to do additional steps to do to clean it up > > You can now deal with that. loadAmber() takes additional optional arguments to deal with project paths. > >> - tools for combining code are missing. That is not a big problem because a simple cat on the console can solve this but would be nice not have to. > > bin/amberc does that. That's actually how the WebDAV of Amber is compiled into one file :) > >> - I prepared two different locations on my web server for the same app. One that is used to develop (the WebDav server access it) and one where only the combined javascript source code is used. This is needed to test the target deployment. Something that could ease this would be wonderful >> >> What keeps me from using it in every project: >> >> - The startup times for amber can be quite huge. All the class initialization is a lot of stuff that burns CPU cycle. On an iphone you don't notice really but on the Nexus 7 tablet it takes 2-4 seconds for initialization and the first page to appear. This is a not a problem for desktop browsers but for mobile ones where I find amber extremely good for. I only used amber in pre pre 1.0 versions and I know there have been optimizations that I didn't test, yet. > > The latest stable release of Amber should be *a lot* faster to load. > >> >> And the annoying "You didn't ask for but I add it anyway wishlist": >> >> - I need to test Helios because I think it solves a lot of issues with the current browser. I don't know how it is supposed to work that you have a second window with the IDE that accesses a page. But I'm sure it works flawlessly or I misunderstood it from the screenshots > > yes, it does :) > >> - retarget files on the disc. I would like to have different paths on disc for separate packages. > > You can also do that now with loadAmber() > >> - amber using websockets to connect to a backend pharo server. This can be used for comfortable code management, amber support for state transport client->server and server->client and to replicate console log to the pharo transcript (or whatever). This is important on mobile devices where sometimes you cannot access the browser console. > > ok, that's an interesting point :) > >> - it would be fine to have support for obfuscation. It is not only for hiding code but also for making it smaller thus saving bandwidth and startup times. This could be the case if the produced javascript code would be work with google closure compiler. Even better would be to have visitor for AST/IR to make it even more effective/less dangerous. > > it does work with Google Closure Compiler, there's an option in bin/amberc too for that ;) >> > > Cheers, > Nico > >> Norbert >> >> Am 14.05.2013 um 15:32 schrieb Nicolas Petton <[hidden email]>: >> >>> Nico >>> >>> >>> On May 14, 2013, at 11:37 AM, Norbert Hartl <[hidden email]> wrote: >>> >>>> I think my last post of this message fell into the time the old mailing list dies. So here it is again >>>> >>>> --- >>>> >>>> We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, …). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, …). >>>> The rehearsal should improve the coordination of several hospitals, firemen…as well as the quickest possible treatment for the injured. >>>> >>>> One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. >>>> >>>> Technically it is done in smalltalk solo. >>>> >>>> The server is a pharo image. It has >>>> >>>> - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data >>>> - a static file server that delivers static resources to client tablets >>>> - a websocket connector that is used by the clients to connect to the server >>>> - a http handler to export data to other analysis tools >>>> >>>> The client is done with amber smalltalk. It >>>> >>>> - loads the web page containing amber from the server >>>> - connects back to the server >>>> - downloads a UI spec for the injured using the tablet to display personalized UI elements >>>> - stores events on the tablet in case the injured is offline >>>> - measures times to instruct the injured >>>> >>>> If you have any questions please don't hesitate to ask. >>>> >>>> Norbert >>> >>> -- >>> Nicolas Petton >>> http://www.nicolas-petton.fr >>> >>> >> >> > > -- > Nicolas Petton > http://www.nicolas-petton.fr > > -- > You received this message because you are subscribed to the Google Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/groups/opt_out. > > |
|
|
In reply to this post by NorbertHartl
Manfred,
thanks. Maybe I missed that when starting with the old version of amber. I'm glad google closure compiler is supposed to work. If it works for the server I'm positive it'll work on the client. Major problems are IMHO if you have variable additions that use underscore as prefix etc. and this should be the same situation on client and server because it is amber dependent. Norbert Am 14.05.2013 um 11:37 schrieb Norbert Hartl <[hidden email]>: > I think my last post of this message fell into the time the old mailing list dies. So here it is again > > --- > > We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, …). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, …). > The rehearsal should improve the coordination of several hospitals, firemen…as well as the quickest possible treatment for the injured. > > One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. > > Technically it is done in smalltalk solo. > > The server is a pharo image. It has > > - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data > - a static file server that delivers static resources to client tablets > - a websocket connector that is used by the clients to connect to the server > - a http handler to export data to other analysis tools > > The client is done with amber smalltalk. It > > - loads the web page containing amber from the server > - connects back to the server > - downloads a UI spec for the injured using the tablet to display personalized UI elements > - stores events on the tablet in case the injured is offline > - measures times to instruct the injured > > If you have any questions please don't hesitate to ask. > > Norbert |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |