Components, tools, files, concepts..

Interchangeability Whether it is an external service of some sort like a backup service, an internal component for writing log entries or a rented database consuming data that can be utilized, when producing statistically useful information, it can be changed with a simple re-configuration. Alternatively a new service or component can be removed/added without changing programming code all over the system by just adding a new factory method or writing custom code for the target in question.

Parameter checkers No request toward the server gets past the parameter checkers. As cyber threats have become worse than ever, it is very important that requests are handled in highly controlled matter and syntactical checking of what is contained in request parameters (ids, textual content, bytes, etc.) is meaningful part of it.

Roles Users may belong to different internal groups, but most of them are plain users, who don't have the managing rights. It is partially managing users' responsibility to make sure that service runs fine. Their special user interface allows them to see service's health status, verify users' emails, read log entries etc. And do they have possibility to read private content users have produced? No, that wouldn't be decent.

Throttling External services might have built-in limits for requests that create, read, update or delete (CRUD) data, which practically mean that sometimes the pace of requests originating from this system need to be slightly slowed down or if there simply are too many requests at the same time, request might have to be dropped altogether. Latter possibility is quite unlikely scenario, but from risks point of view, it has to be taken in account. However, most of the time users aren't using those throttlable external services as larger part of the time they spend for a project is used in other activities.

Encrypted connection, HTTPS Rest assured that it would take hundreds of years for someone, who is eavesdropping your Internet usage (think wireless connections in, e.g. cafeteria) to be able to capture and read what this web application is communicating with the server part of it, as all that communicating is encrypted and can not easily be decrypted. Used encrypting method is so strong that it wouldn't be necessary to protect your login credientials more thoroughly, but as such is already implemented meaning that your password is never sent as plain text over the Internet, why take that functionality away? It is based on double hashing technique, for those who are interested about the details.

Multidevice support, responsiveness The service is mostly meant to be used with a mouse-enabled computer, but as these days those come in variety of sizes and resolutions, it has made sense that the service should adapt automatically to changing sizes of usable screen / window dimensions. This can be seen in effect by changing the width of a browser window. In simplest sense the adapting means that when available width is larger than x, then certain user interface elements can be fitted next to the other, but who is to say, when certain elements shouldn't be side by side, but above or below the other? Some guesses have been made. There are also views, where the purpose for decreasing the width of a browser window is meant to be used for hiding certain elements as sometimes it is subtle enough change for being able to focus better, when there are less elements in the view to perceive.

Broad browser support There was time, when it was really quite painful to develop web applications that would function and look identical, when used in different browsers, but nowadays it is much more easier as differences between implementations of standards have vanished in many meaningful areas. Sometimes simple waiting for browsers to support something in common ways isn't enough as browsers tend to have their own unique features, which aren't derived from standards by some committee, but which would be nice have supported in other browsers, too. In those cases suitable JavaScript-library simulating lacking features might be found or if not, one could fix the lacking support of a feature by himself, but luckily that is often not required.

Image upload bypasses server, mostly As processing uploaded images could take more time than any other request originating from the web client, it has made sense to bypass the server for the part that considers transferring the actual bytes. They would end up to the certain 3rd party operated image storage service anyway. Naturally it is first (programmatically) asked, per request basis, if it is ok for a logged in user to upload an image as otherwise external storage would suddenly be filled with strange photos having no relation to anything. That means that anynymous users can't distrupt operating of the services and that actions of logged in users are monitored for meta data like transferred bytes, amount of photos etc.

Companions and nuances Programming code of the client part of this service is using unique feeling dividing of responsibilities between participating classes. Companions (e.g. WritingcollectionCompanion and SearchCompanion) handle the higher level stuff like beginning operations and reacting to possible errors. Similarly named nuances (e.g. WritingNuance and ThingNuance) handle certain kinds of smallish tasks like changing a value in a pane that display information, enabling/disabling buttons and forwarding edited value of a table cell to corresponding companion method. In the user interface their collective responsibilities could be pointed with rectangular areas. Companions act also as controllers in MVC-based architectural pattern (Model, View, Controller), wherein models and views are often handled by Backbone and Backgrid (JavaScript libraries).

Needgroups and workers When ever the server part of the web application is approached with a request of some sort, that request must have a needgroup defined. If it is related to importing then it is a controller of a importing needgroup, which will handle the request. And just like on the client-side the responsibilities are divided in certain ways, server-side has its own means for deciding what component or subsystem does what. Actual processing of a request goes through a creation of a needgroup and required controller, which acts as the one, which handles the higher level processing with aid of worker-methods. It is also about readability of the programming code.

Tomcat, beans and Weld The service saw the first light as an application meant to be deployable to Tomcat, a servlet container. At the time it was thought that not all enterprise Java technologies would be needed and thus Tomcat would be just fine and that Glassfish or WebSphere wouldn't be needed. However, researching of how could it be possible to let certain software components live between different requests originating from any user and still do this while using Tomcat lead to the finding of the Weld. From its website: "Weld is the reference implementation of CDI: Contexts and Dependency Injection for the Java EE Platform which is the Java standard for dependency injection and contextual lifecycle management and one of the most important and popular parts of the Java EE platform." Among others statistical operations, logging and database access are the ones encapsulated in the separate long living components being available anywhere, where they could be needed or could be useful.

Multilanguage English not fancy enough language? Finnish then, perhaps? No problem, let's just change the language-parameter and voila, language of the user interface has changed completely. Or atleast, it would change, if somebody had actually done the translation, but the code supporting translations is already baked-in.

Payment methods: PayPal and Stripe-supported credit card payments It probably wouldn't make much sense to build custom payment system, when there already exist few, which can be integrated, if the developer has the required know-how. For users, Paypal is offered as one method of payment and Stripe is handling the credit card processing. Companies providing these payment systems (or gateways) also handle all the (possible) fraudulent payments and aid in unlikely(?) cases when there's a dispute over refunds. Offered payment methods are very secure and all the transactions are logged for later inspection, if there's ever need for such.

Registration methods: Facebook-aided and via link in an email If a potential user is already logged in to his Facebook-account, he can sign-up very quickly. Practically Facebook-aided login means that user does choose a login name, but the email and his name is fetched from his Facebook-profile - if permission for such is given, when it is asked. Email address gets automatically verified this way. Another way to create a new account is to let the service send email to given email address, which will contain a clickable link that will lead to the creation of a new account. In both cases password will be preselected and user is strongly recommended to change it after logging in.

JPA This is one of the best parts of the Java EE Platform, but one utilizing it have to be extra cautiousness, as a user will certainly feel it, if usability of the service becomes laggy or buggy. Basically JPA (Java Persistency API) allows developer to map relational database entities to Java-objects with extra functionality like caching of requests for selecting data rows. With aid of the Eclipse (integrated developing environment) usable Java-objects together with configurating annotations are generated almost automatically, but that can get a developer only so far. Especially if database is distributed and there are multiple servers handling requests originating from a web client. If one implements it wrong, old data might reside in a cache until it expires, meaning that one user could see what is the latest, while other only thinks he is seeing the latest, when he actually isn't.

Queue messaging, Web Sockets When developing an information processing system, it is not always required to process everything at the time a request for such arrives. Sometimes it is just fine to schedule it to be done at later time. This might mean, e.g. "not no, but after a few seconds, maybe" or "when the service is less stressed" and can be applied to many kind of situations. If it was the web client, which originated the request, it normally just waits for its request to be answered until it continues to do something else, but by utilizing queue messaging technology, web client could be informed about the answer at a later time. This is where Web Sockets come in picture, which means that information can be pushed to the web client without it explicitely asking for it. One area where queue messaging can be used, belong to fire-and-forget -scenarios like "send an email, following first in, first out principle".

TestNG, ReportNG, Mockito Any method in the programming code should be well-defined, not trying to accomplish something too complex by itself and hopefully it should consist less than 30 lines of code or so. These methods, which handles certain task, are one of those that can be called as units in testing terminology. TestNG is wonderful tool for unit testing, while also giving possibility to group tests under different categories and test suites. It can be used together with Maven, the build manager for Java projects. For slighly better test reports one might want to use ReportNG as a plugin for the Maven. Mockito is also related to testing, but in can be characterized to be useful for "faking" what a method or component should return as a result. Useful in situations, when it is not allowed, suitable or possible to make real requests like when a target unit is used to execute something that can not be rollbacked (the act of reversing or undoing something). Other types of testing is also used routinely (e.g. load testing and functional tests).

Maven The web application is Maven-based meaning that the final web application is build according to certain configurational rules, while also fetching 3rd party components from certain repositories. Maven makes it easier to migrate from server to server, if that ever becomes necessity.

Foundation, jQuery-plugins Client-side part of the service is mostly based on Foundation, which is a JavaScript-based framework. It defines certain moldable starting point for developing the client-side of a web application including set of visual widgets and non-user-faced functionality that makes developers work easier. jQuery-plugins are used in certain special cases like when it have to be certain that something operates similarly in differents browsers and starting to code such from scratch wouldn't be beneficial in any sense.

Managebility

Log entries in case of errors and strange occurrances A log entry is written, when some goes wrong. And it will. In normal scenarios everything that happens "behind the scenes" happens in highly controlled fashion and there is no actual need for automatic log entries that only tell that something has been handled just like it was planned to be handled. However, there will most certainly be technically more advanced users, whose intentions are saturated with ideas related to destruction, faking and disturbing. They might try something like changing the hidden id-parameter that is sent along with the writing that is about to be saved, so it would not change a writing of their own, but someone else's. Or they might bombard the system with some automatic bot system that sends lots of meaningless requests toward the server. These try-outs and resulting errors need to be noticed, and thus the logging component is an absolute requirement. Ofcourse there are also situations, where nothing malicious has happened, but it might just be that an external service is not available, when it is supposed to be. Developers need to become aware if such occurs often, because it affects the user experience.

Statistics based on meta data Private content that users produce is not considered meaningful for statistical purposes, even when it would be available in the database along immediately available data like last edited -dates and derived data like median amount of catalogs per user. But just about anything else might be. Wonderful realizations will occur, when there is enough meta data that can be seen as describing users' behavior. Such will help shape the future development and next iterations of the service.

Dual databases SQL-based relational database is the right choice, when database tables can be normalized to the Third Normal Form (minimized data redundancy, free of update anomalies etc.) and enties in it are not isolated, but have relations between each other. However, if database designer would be in need of presenting inheritance, it would become with many disadvantages, if he tried to create database structure supporting modelling of different kind of types of similar document (e.g. writings have multiple different types having different sets of fields for the user to fill). One alternative would be to not use relational database at all and choose to use a document database, which support both the relations and inheritance, but for the sake of managebility, one might - paradoxically - choose to use both and keep them syncronized. MongoDB has been choosen as the one, which store documents that express inheritance and MariaDB as the one storing most of the other entities. The way they are used in the programming code makes them low coupled (manner and degree of interdependence between software modules) meaning that it will be easy to switch to another set of databases if it ever becomes necessity.

Easy-to-add external services (backup storage, image sources, etc.) It is a sign of well-structured system design, if new software components like the ones that integrate external services to it can be added without beginning from explaining to oneself what this and that part of the programming code does before development can continue. It should be enough that developer just glance through certain related parts of the programming code and then starts writing integration code as "recreating required understanding" can really be that quick - even after a delay of few weeks or so.

Dashboard for managing users Normal users have their own user interfaces, but managing users have a dashboard, which allows them to see service's health status, toggle certain features on/off, verify users' emails, read log entries etc.

Server's health monitoring, internal metrics and mobile alerts There is no shortage of service providers that can be utilized for checking if the web application is still usable from different parts of the World. If there's a reachability problem, these services can be configured to send alerts to a mobile phone. There are also internal metrics for deciding if the server containing the application is approaching a minor or major problem, which might occur if a huge amount of users use the service at the same time.