19 Feb

Templated Components with Knockout

Templated Components

Some time ago I wrote about our best practices for creating components. Even though components have been a great relieve to us when developing new features, there have been limitations as to their flexibility and reusability. For example, when using a component for different tables, each of the tables needed to have more or less the same layout and the same number of columns. To a certain degree, we could adapt the tables with the help of boolean variables, but this did not exactly increase the readability and quality of our code. So we ended up creating a whole range of different table components, even though their basic logic was the same: they all needed to do sorting, scrolling, filtering, etc.

This was when we started to investigate and found out that Knockout now allows passing markup into components. Thus we can have the same logic for all tables but use completely different layouts for them.

Example: Templated List

Here is a very simple example of a templated lists. For passing template into the component, any html code can be placed inside the component’s custom html element:

The component can inject any template into its html by using the knockout template binding. The parameter ‘nodes’ specifies an array of DOM nodes that are to be used as a template, the ‘data’ parameter supplies the data for the template to render.

The html we placed between the component tags can be accessed via $componentTemplateNodes:

The resulting list looks like this:

Patients

  • Name: John Smith, birth date: 23.09.1952

  • Name: Jenny Smith, birth date: 14.02.1963

Since we do not only want to use the component for patients, but also for orders, we use the same component again in a different view, and pass different template this time:

So we get a completely different list:

Orders

  • Name: John Smith, address: 111 Kirby Corner Rd, Coventry CV4 8GL, status: open

  • Name: Jenny Smith, address: Waterside, Stratford-upon-Avon CV37 7LS, status: delivered

Having understood the principle of how templated components work, we can now move on to creating more complex templated components that inject different parts of template into different places in their view. I will explain in one of my next blog post how this can be done.

Share this
28 Okt

Projekt “Mediheld” erfolgreich abgeschlossen

Wir freuen uns sehr, dass unser Projekt “Mediheld” erfolgreich abgeschlossen ist. Naja, so richtig abgeschlossen ist ein solches IT-Projekt eigentlich nie, aber so berichtet es jedenfalls “Der Neue Tag – Oberpfälzischer Kurier”.

„Mediheld – gesamtheitliche Versorgung im ländlichen Raum“ verfolgt das Ziel, die medizinische Versorgung in dünn besiedelten Gebieten zu verbessern. Gerade in ländlichen Regionen müssen in der häuslichen und ambulanten Pflege oftmals beträchtliche Fahrtstrecken zwischen Arzt, Apotheke, Sanitätshaus, Pflegdienst und Patient bzw. seinen Angehörigen zurückgelegt werden. Hinzu kommt, dass in den Apotheken Arzneimittel häufig nicht vorrätig sind oder aufgrund mangelnder Kommunikation und Koordination die Patienten mit falschen Medikamenten versorgt werden.

Um diesen Problemen entgegen zu wirken, haben sich Akteure aus der Wirtschaft, Wissenschaft, Gesundheitsversorgung und Politik zusammengeschlossen, um eine zukunftsträchtige Lösung zur gesamtheitlichen Versorgung im ländlichen Raum zu erarbeiten. Gefördert wurde das Vorhaben durch das Bayerische Staatsministerium für Wirtschaft und Medien, Energie und Technologie.

Unter der wissenschaftlichen Begleitung des Fraunhofer-Institutes für Angewandte Informationstechnik in Bayreuth und dem Lehrstuhl für Öffentliches Recht, Sozialwirtschafts- und Gesundheitsrecht der Universität Bayreuth haben wir eine einfach zu bedienende App entwickelt, die alle Beteiligten des Versorgungsprozesses unter Beachtung der rechtlichen Vorgaben miteinander vernetzt und so die Kommunikation sowie die Koordination zwischen Arzt, Apotheke, Sanitätshaus, Pflegedienst und Patient  bzw. seinen Angehörigen erleichtert.

Bedient werden kann die App mittels Smartphone, Tablet oder PC. Jeder der Beteiligten hat zu jeder Zeit Zugriff auf die für ihn relevanten und für seine Augen bestimmten Daten. So ist beispielsweise der Patient immer über den Status seiner Bestellung informiert, die Apotheke und das Sanitätshaus haben direkten Zugriff auf die vom Arzt oder Pflegedienst getätigten Aufträge und der Arzt kann die vom Patienten benötigten Rezepte sofort bearbeiten. So wird auf ganz bequeme Weise eine effiziente und effektive ambulante Pflege ermöglicht.

Die Schug-Gruppe aus Eschenbach hat uns als Projektpartner bei der Modellierung der komplexen Abläufe und mit dem Einsatz der Prototypen in ihren Einrichtungen bei der Weiterentwicklung der “Mediheld”-App hilfreich unterstützt. Durch die Erprobung in der Praxis, das konstruktive Feedback der Anwender und die gute Interaktion der Beteiligten konnte der “Mediheld” von uns fortlaufend optimiert werden.

Jetzt geht ein Projekt zu Ende, das in den letzten Monaten im Mittelpunkt unseres Alltags stand. Wir sind mächtig stolz auf uns, einen so wichtigen Beitrag zur Versorgung im ländlichen Raum geleistet zu haben – ganz zu schweigen von all den kleinen und großen technischen Herausforderungen, die wir auf dem Weg gemeistert haben! Aber ein bisschen traurig sind wir auch, denn unser “Mediheld” ist uns allen ans Herz gewachsen … Aber ganz vorbei ist es zum Glück doch noch nicht: Wir streben an die App “Mediheld” deutschlandweit, später international, an Ärzte, Apotheken, Sanitätshäuser und Pflegedienste zu vertreiben.

Wenn auch Sie mit zu den Benutzern von Mediheld gehören möchten, besuchen Sie unsere Webseite www.mediheld.info und fordern Sie noch heute eine Demoversion an!

mediheld

Share this
10 Okt

Improving the Reportheld website!

Well, we had to learn it one way or another – marketing matters. We are very happy with the word-of-mouth customers we are getting, and they are getting even more. To tell you the truth, it is pretty awesome, what kind of reception Reportheld got without us doing much (or any?) marketing up to now.

So without going any further, first and foremost: Thank you to all our loyal customers that are talking so enthusiastically about our solutions. You rock!

As always though, for us to be a real startup we need websites. So we have created the Reportheld website with additional, dedicated information about that cool product. Of course, just as software, a website is never done, but for now you can read all about the wind power centered Reportheld. We plan to put all the other business sectors on there that already benefit from our easy “a picture says more than a thousand words” workflow.

Let me invite you to take a look at the new homepage and let me know what you think!

Share this
12 Sep

Presenting Reportheld at Husum Wind Conference

Next week we will be presenting our Reportheld Inspection Solution at the HUSUM Wind 2015. Together with our largest customer and partner BayWa r.e. you can find us at the BayWa r.e. booth 2D19.

With a large install base and a fast growing international group of customers Reportheld prides itself of being easy, stylish and efficient. With its unique workflow across multiple device formats, your employees can use the right device at the right time. No matter, if iPhone, Android, Windows Phone – or if it’s on their laptop. It doesn’t matter. No more manual synchronization or outdated protocols. And the best thing: Multiple engineers can work simultaneously on one protocol with multiple devices!

Find us at the booth and learn in which ways Reportheld helped BayWa r.e. shape, optimize and improve their operation and maintenance of wind turbines and solar plants. Talk to us how this next generation CMMS Software can help you win customers, optimize costs and at the same time make your employees happier.

See you at booth 2D19!

Share this
18 Aug

Best Practices for Creating Knockout Components

With the release of version 3.2.0, knockout introduced Components, which are a clean and powerful way of organizing and structuring code. We have increasingly used components in our projects since then and enhanced our understanding about what is a good component and what is not. In this blog post, I will present our best practices for creating components.

Components – general principles

The idea behind components is to create self-contained chunks of code that fulfill two main purposes:

  • reusing pieces of code
  • simplifying code by breaking it into smaller pieces which each encapsulate a certain functionality; this makes it easier to maintain and understand the code

In order to be self-contained and thus easily reusable, components must be only loosely coupled to the part of the application they are embedded in.

Registration

Knockout components combine a viewmodel and a template. In order to start using a component, it must be registered with the ko.components.register function. The function specifies the viewmodel and template, both of which should be loaded from external files and not hardcoded into the registration.

Of all the different ways of specifying the viewmodel, we use the createViewModel factory function. It is called with the parameters params and componentInfo, where params is an object whose key/value pairs are the parameters passed from the component binding or custom element, and componentInfo.element is the element into which the component is being injected. By passing both params and componentInfo into the constructor, we ensure that both are accessible in the viewmodel:

View

For injecting a component into a view, we use it as a custom element. We prefer this over the knockout component binding, which binds the components to regular div elements, because it is much more elegant and straightforward:

To supply parameters to the component, we provide a key-value object as params attribute. The properties of this key-value object are defined in the containing viewmodel and will be received by the component’s viewmodel constructor.

The component’s view should have as its outer element a distinctive div container with the component name as its class name:

This makes it easier to address the component and to provide component-specific css.

Since we want the components to be reusable, the view must not contain any ids. Having ids in the component would make it impossible to use a component multiple times within one page.

Params

The properties which are passed over as params into the component are the only means of communication between the component and the containing viewmodel. In order to maintain a loose coupling, we must never pass the complete parent viewmodel into the component. This would make the component very hard to reuse and the viewmodel very hard to change.
Instead, only those properties and functions should be sent to the component that are really necessary for displaying and manipulating the component’s view elements.

For better keeping track of what the properties are meant to be used for, we have established the following naming convention: if the component needs to call a function of its containing view model, the parameter for this function should have the word ‘callback’ in its name (such as ‘cancelCallback’). If, on the other hand, the containing viewmodel needs to call a function from the component, the function’s name should contain ‘ComponentAction’, such as “findAddressComponentAction”.

Since a component should solely be concerned with itself and not with the container in which it is embedded, we should never pass over a view element from outside the component. Moreover, trying to access a component via their containing elements is a dangerous thing to do especially if a component is used more than once within the container. Instead, a component can be accessed unambiguously via the componentInfo which is provided by knockout’s createViewModel function and should be passed into the constructor if the viewmodel needs to access it.

Viewmodel

A component should act as a black box which takes care of all the functionality that is expected from it. Therefore it should implement all the component-related logic. For example, if we create a table component, the viewmodel must provide the functionalities for searching, sorting, scrolling, etc., rather than the containing viewmodel.

Besides, the viewmodel class should always have a dispose function in which any resources are released that are not collected by the garbage collector, such as subscriptions, event handlers or ko.computed properties (if they are not pure computed properties). The viewmodel should have this dispose function even if the function is empty, as a reminder that we do need to remember to clean up when we extend the component later. The dispose function is called every time just before the container element is removed from the DOM.

Share this
07 Aug

Checklists for improving the development process, part three: adaptations of the checklist for creating pull requests

In my last two blog posts about checklists I have presented some checklists for handling pull requests and described their effect and the team’s reaction. I have also stated that checklists continuously need to be altered and adapted in order to be truly helpful. In this blog post I am going to explain which changes I have made to the checklist for creating a pull requests and what were the motivations behind that.

Alterations and adaptations of the original checklist

Putting the checklists on trial in our real world workflow revealed several shortcomings and flaws in them that needed to be fixed. For example, I soon discovered that even though it leaves the programmer more freedom at going about his tasks, the list for creating pull requests did not work out as a do-confirm list. The process turned out to be more complex than I had at first imagined; for example, it is important that the latest master is merged into the branch before running the _common solution gulp task on the latest _common master branch, otherwise running the gulp task would propagate changes into my branch that are already in the master branch. So I changed the checklist into a read-do list.

Another thing I realized was that it was impossible to use one and the same checklist for creating pull requests for a regular branch and for a hotfix branch. The list requires us to merge the master branch into our branch, but a hotfix branch will end up in the production branch, where the master branch should by no means end up! So I created a separate list for dealing with hotfix branches, and added some more steps to it.

Moreover, having a look at our application’s unit tests made me add a further step to the checklists. Many of the tests failed because they had not been run for quite some time. Adding the step ‘run tests and make sure they succeed’ to the checklists, I hope that in the future the tests will be used more frequently. This will not only ensure that the tests are always up-to-date, it will also help us discover bugs our new changes would have introduced to the system.

So, this is the updated version of the checklist for creating pull requests:

new version of the checklist for creating pull requests

Since it had been me who ended up fixing all the broken tests, I am especially happy to see that the team members carefully follow this new step ‘run the tests …’ 🙂

Share this
05 Aug

How to use knockout-bindings to set style of DOM-element

Knockout.js is a very powerful MVVM framework to do some web-application.
I want to explain a trick how you can bind a style of DOM-element in runtime.
The simplest way to use a css-binding is:

<label data-bind="css: 'red'">

so your label will be defined by class ‘red’:

<label class="red">

Another way goes through the binding parameter ‘attr’. You can set all attributes of DOM-element during this parameter directly, but if you want to set the attribute ‘class’ you have to use the name ‘class’ as follows:

<label data-bind="attr: {class: 'red'}">

The binding during ‘css’ attribute adds a class name to an existing list of classes.

<label class="warning" data-bind="css: {red: isDangerous}">

The class ‘red’ will be appended to the class ‘warning’ if the function isDangerous() returns true.
Unlike that, the binding during the parameter ‘class’ overwrites the attribute ‘class’ of an element completely.
Now, imagine the following problem: you will show a collection each element of which has a common class ‘nice’. A loop through the collection will be looked as next example:

<!-- ko: foreach myCollection -->
<label class="nice" data-bind="text: someText"></label>
<!-- /ko -->

Then you want to enable or disable some rows by function isEnabled(). It’s quite easy too:

<label class="nice" data-bind="text: someText, css: {enabled: isEnabled}"></label>

At finally you want set some unique row’s style based on row’s position. You can use something like ‘row’+$index() :

<label class="nice" data-bind="text: someText, css: {enabled: isEnabled, 'row'+$index(): 1}"></label>

But it doesn’t work because Knockout doesn’t understand dynamic names of related parameters!
In such case the parameter ‘class’ helps well. We know that it overwrites the list of classes of DOM-element, because of this we move the description of classes from DOM-element in Knockout binding:

<label data-bind="text: someText, css: {enabled: isEnabled}, attr: {class: 'nice row'+$index()}"></label>

It works and seems good, but you’ll notice soon the class ‘enabled’ will be never set. Why? Because the parameter ‘attr’ will overwrite it.
The solution is very simple: the attribute ‘class’ must always be placed before the parameter ‘css’!

<label data-bind="text: someText, attr: {class: 'nice row'+$index()}, css: {enabled: isEnabled}"></label>

Now it works very well.

Share this
31 Jul

Checklists for improving the development process, part two: effects and reactions

A couple of weeks ago I wrote a blog post about checklists and how I created several checklists of my own to improve the way we handle pull requests. Today I’d like to share the results of the first weeks’ trial period: which effects did the checklist have on the development process and how does the team feel about them.

Here are the two checklists again as I originally drafted them:

checklist for branching

checklist for creating pull requests

Effects on the development process

After I had read so much about how checklists seem to be able to work wonders in other professional areas, the results of the first week trial period were somewhat sobering to me: during this week almost everything happened from a broken build to changes not being forwarded to the global common solution. Well, you cannot change a programmer’s habits overnight, and to be fair, not all of those incidents were caused by not using the checklist…

As the weeks passed on, however, there were several situations in which the checklist helped me detect changes that I had forgot to forward to the global _common solution, that would have been overwritten by the next running of the _common solution gulp task. And I was delighted to observe that almost all of the Pull Requests had the latest master branches merged into them. Also, there were much less cases in which some other branch than the master branch ended up in a Pull Request, and if there were, this was absolutely necessary and explicitly allowed.

What the team members think about the checklists

Even though the checklists have undeniably shown some positive effects, I know that not everyone uses the lists at all times. To be honest, every now and again I catch myself thinking ‘do I really need to go through that checklist now?’, especially if I am in a hurry or think that I have already done all the steps. But someone needs to set a good example…

So, I think while we generally agree on the importance of executing the steps set down in the checklists (haven’t we all been bothered by merge conflicts because we forgot to merge the latest master?), we consider it somewhat below us to actually use the list for that. After all, we are all smart developers who have coped without checklists for many years… so we just try to remember everything by heart, and maybe save the couple of minutes it takes to open the checklist and make sure we REALLY have done everything that the list requires. Needless to say that this is not exactly what a read-do list is meant for…

Conclusion

Even though the checklists are not used as regularly as I’d have wished for, they have increased the team’s awareness for the necessity of executing these steps. It is still better if the steps are done by heart and in the wrong order, than if they were not done at all.

We all generally agree that checklists are a good idea and that they are helpful, and we all know in our hearts that actually we should be using them. I firmly believe that if we continuously optimize the checklists and constantly adapt them to our processes, the acceptance of them will grow and we will slowly get accustomed to using them.

Share this
30 Jul

Kurierdienst DHL Kurier Extension für Magento

Mit dieser Extension erhalten Ihre Kunden genau zum gewünschten Zeitpunkt die bestellte Ware! Durch den neue Service von DHL Paket DHL Kurier können Sie mit diesem Magento Modul Ihren Kunden eine ungeahnte Vielfalt an Einstellmöglichkeiten bieten.

Das DHL Kurier Plugin wurde speziell für Magento entwickelt und angepasst. Besonders die intelligente Auswahl der möglichen Versandarten macht diese Extension sehr intuitiv und einfach zu bedienen, sowohl für Sie als Shopbetreiber, als auch im Besonderen für Ihre Kunden. Gerade durch die neue Versandart mit Kühlung ermöglicht die Extension in Verbindung mit DHL Kurier Lebensmittel oder sonstige verderbliche Ware schnell und sicher zum Kunden zu transportieren.

Machen Sie es Ihren Kunden einfacher Ihre Ware schnell und ohne Komplikationen zu erhalten. Es steigert die Kundenzufriedenheit messbar!

Gleich in unserem Magento Plugin Shop bestellen!

Share this
20 Mai

nginx gegen LogJam absichern

Sicherheit und Absicherung von Servern ist wie ein eisernes Vorhängeschloss – wenn man es nicht pflegt und prüft, rostet es und wird immer weniger sicher.

Wir sind uns unserer Verantwortung sehr bewusst, dass Sie uns Ihre Daten anvertrauen. Daher sind wir immer daran interessiert unsere Server gegen gängige und neueste Attacken zu messen.

Heute ist die sogenannte LogJam Sicherheitslücke bekannt geworden. Dabei sind es vor allem die Browser, die die Sicherheitslücke aufreißen. Allerdings kann man hier in diesem speziellen Fall auch als Serverbetreiber die Anwender durch eine richtige, härtere Konfiguration des Servers schützen.

Wir nutzen nginx als unsere Edge, um unsere Backends gegenüber dem offenen Internet zu schützen. Daher haben wir uns heute, inspiriert durch LogJam, unsere nginx Konfiguration nochmal mit der Lupe angeschaut.

Die wichtigsten Punkte für die ssl Sicherheit sind in nginx die Direktiven ssl_ciphers und ssl_prefer_server_ciphers. Damit kann man unsere ssl Verschlüsselungen verbieten und den Browser und Server anweisen dem Server bei der Aushandlung des ssl Ciphers mehr zu vertrauen.

Zusätzlich ist es immer empfehlenswert ssl auch durch einen möglichst starke Diffie-Hellman Gruppe zu erzeugen. Diese wird mit dem Befehl

erzeugt. Eingebunden werden kann diese dann über ssl_dhparam in nginx.

Überprüfen kann man die Einstellungen des Servers über weakdh.org. Schön, dass unsere Server dort “Good News!” verkünden. Wir sind gespannt, wann die nächste Sicherheitslücke unsere Server testen wird. Wir bleiben auf jeden Fall für Sie und Ihre Daten am Ball!

Share this

© 2015 groupXS Solutions GmbH. All rights reserved.