DEV Community: Oded Sharon

OpenFin from the Front-End Developer Perspective

Oded Sharon — Fri, 16 Apr 2021 11:00:41 +0000

I would like to introduce you to OpenFin and go over its capabilities and limitations when creating a JavaScript-based multi-window desktop application.

The first thing I was happy to learn about OpenFin is that its description "Financial Operating System" is a bit misleading as it's a View-manager more than anything else. This makes it useful far beyond the world of fin-tech: Essentially any application that shows many roughly similar views (or panels) can benefit from OpenFin’s out-of-the-box customisable View-management capabilities. These can range from server/network status control panels to multi-window Video chats.

As its foundation, OpenFin uses several well-received technologies that is worth exploring to have better understanding what it is and how it works. At its core it’s based on Chromium - a headless (i.e. without user-interface) browser (which Google Chrome is based on). It is then wrapped with GitHub’s Electron, which is a container to run web-applications as a desktop application. And finally, OpenFin itself provides few additional features, such as improved security, View-management and its InterApplicationBus which allows all the views to communicate with one another as well as providing API for external application. This allows the Views to communicate with a JAVA application, for example.

An OpenFin application consists of one or more window, each with its own set of Views. These views are arranged in a “layout”. A layout is a (JSON-based) description of the View arrangement in a particular window. It is transient, in the sense that it can stored, restored, or even shared with other users. A “Snapshot” is similar concept, but it extends to the arrangement of all the currently open window. It’s important to note, however, that snapshot don’t refer to layout (a change in the layout won’t change the pre-saved snapshot). I found the name “Snapshot” to be slightly misleading as one might understand to include the state of the data at the time taken. A proper name, I believe, would be “workspace” as it merely saves the windows (position and size) and their internal arrangement of Views.

The views are displayed in “layout-container” HTML element. This allows the developer to add additional features (such as title bar or a sidebar) to enhance the application, but it’s important to understand that the views themselves run on separate processes and are not part of the HTML file. It has its benefits of increased security and crush-protection, but also its downsides, as it’s impossible to have HTML elements (such as dialogs or drop-down menu) on top of the views and communicating with Views can only be done through the InterApplicationBus.

OpenFin is responsible to update the position of the views in accordance to updates in the layout-container – moving, resizing, and even hiding. However, it assumes that the layout-container is displayed in its entirety (i.e., no scroll is allowed). It even goes beyond, and the window’s scroll event isn’t being triggered. It makes sense that the Views can’t be displayed partially if you consider that they’re not constrained by the window rather than floating above it.

The layouts themselves are fully customisable and the user may move the views however they see fit. It’s also possible to lock a layout and prevent tearing out or dropping in new views. However, the customisability isn’t very configurable, as it’s impossible to lock the layout to a particular structure (for example, forcing the layout to “fixed-width columns”). Additionally, the views are always resizable. As every layout-change triggers an event, it is possible to force the layout into the desire state, but that would require additional implementation and the UX might be frustrating as it will look possible to “break” the structure, which will lead to user’s frustration. The inability to lock the width of the Views raised an issue in our development as it will require additional time developing responsive Views and at the overall time for the project, we’ve considered reimplementing our own version of a layout-manager particularly for this cause.

OpenFin comes with several plugins or services that enhances its capabilities. For example, “openfin-layouts” allows to easily snap two windows together (and then move them as a group). The act of docking windows was incredibly simple – installing the node-module, adding a reference in the manifest file and that’s it. The reverse action, of undocking the windows, turned out to be much more complicated, as the original library code relied on old version of OpenFIN and files that were since then deprecated. I manage to solve it by copying the deprecated files to my project, which is less than ideal but it at least it worked.

However, with all of the Openfin’s benefits, it's important to point out it's not meant to run on mobile devices. Both Electron and OpenFin are desktop-container aimed to work in any desktop OS (Windows, Linux, MacOS) but not on mobile devices (iOS, Android). Some of the code might be usable with similar mobile-containers (ReactNative, PhoneGap,...) but it will require consideration at architectural level and might limit the features that we can use out-of-the-box from OpenFin (namely the InterApplicationBus). For mobile devices that would be less of an issue as the layout would be constrained to a single column anyhow, but for tablet it seems like a missed opportunity to need to implement a separate solution from the desktop version.

In my conclusion, OpenFin is great for what it does, but it has its limitations, incompatibility with mobile and tablets is the most critical one. It’s ideal if the development-team would like to focus on developing the views themselves and agree to accept the View-manager with its quirkiness and limitations as is. I think that at least in that sense, it accomplished what it set out to do – which was to provide the framework and allow the developers to focus on the business part of their product.

Errors, Bugs and Features

Oded Sharon — Sat, 27 Feb 2021 21:35:35 +0000

I did a little mapping out of different error types a developer might encounter. It should be useful for junior developers but even more experienced developers might find the classification worth discussion.

The most basic errors are syntax errors, such as typos. These are also called compilation errors as they can usually be detected when compiling the code. In intercepted languages (such as javascript) merely loading the file (in the browser) will produce an error. So they're easy to spot and easy to fix as the compiler/browser can easily point out the part that didn't make sense to it. Having a good IDE (Integrated Development Environment), should save one the need to actively compile as the IDE itself will warn when it'll notice that things don't make sense.

Things can get trickier when the typo is "i" instead of "j" (for index variables), for example. True this is a mere typo but if such a variable exists, the compiler won't complain and we'll get a semantic error or a Logical error. In this case, the programme will run but will not do what was expected of it. And now the things might happen - the good case is that the programme will crash or have any other clear indication that something is wrong; the bad case that the programme will run normally but occasionally (depending how deep is the typo buried) produce wrong results.Having (automated) tests that check your code works as expected should help you avoid semantic error.

Another kind of error are runtime errors. These happen when the running code does something the developer didn't expect, such as trying to access an out-of-bound array item, or when the user enters invalid input. Brenan Keller told the following story -"A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd;First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.".It's true that not everything can be predicted, and therefore it's always good to have try{}-catch{} segments around shady parts of your code - namely user input and data fetched from external sources.

But all these were the easy errors. The difficult errors are the ones you don't see coming - Randomosity errors, such as race-condition errors.Consider the following story - A software company was struggling to find the cause for their systems to crash every night, but when left unattended as whenever an engineer left to monitor the activities overnight, everything seems to be working fine. It took them a while to realise it was the screensaver causing the crash so whenever the engineer checked the system he simply prevented it from going to screen-saver mode.There is no clear solution how to avoid such errors but there are measurements one can take to eliminate alternative causes - such as testing units separately, integration between the units and testing end-to-end to try guesstimating what might differ in the failing scenario.

Similarly, There are issues that don't make sense. Consider the following story (well elaborated by Abdul Nasir Shaikh) about a customer complaining to General Motors that his car won't start whenever he buys vanilla ice-cream, while all other flavours seems to work alright. As ridiculous as it may sound, GM sent an engineer to investigate and he learnt that since vanilla ice-cream, being a popular flavour, is located at the front of the store, the engine doesn't have enough time to cool down, while the rest of the flavours were at the back and posed no issue. The overheating problem was fixed and everybody was happy. It's important to note that the error was as real as it gets, but its phrasing sounded odd. When trying to solve such a mystery, it's always important to question if we frame the problem correctly.

And lastly, we have the all-time favourite "It's a feature, not a bug". Consider the following video -

Another example would be the iPhone's limited multi-tasking capabilities. Although some multitasking is possible, most of the iPhone apps hibernate whenever they're not in use. In most scenarios it makes sense, however it has been a long-time rant that it's not possible to play youtube videos in the background. The "feature" can be justified, at least from the developer's point of view, but for the user who complains about the bug - it's a failure of understanding the user's need.

And that is the worst kind of error a programme might have- it's working just fine - but it doesn't behave how the user expected it to. Behaviour-driven-design should resolve such issues, but that is assuming of course there weren't any errors in the behaviour-analysis stage itself, which is usually outside the developer's scope.

To surmise - compilation errors shouldn't be an issue at all; logical errors should be covered by proper tests, random errors can be avoided by keeping high test coverage and behaviour-driven design should help avoid "feature-not-a-bug" error when done right. I think it's useful to frame the error in the right context.

Surely you have fancy investigative/facepalm bug stories of your own. I would appreciate if you can share them in the comments - especially if they don't fall under any of my categories ;-)

I learned vue.js over the weekend

Oded Sharon — Tue, 26 Jan 2021 15:55:16 +0000

Oftentimes when I talk with recruiters they'll ask about my experience level in a particular technology or more specifically a JS framework. I find this question a bit odd as surely I can easily learn whatever framework in question in a reasonable time frame. That said - show me a JS framework that takes more than a month to learn and I'll show you a framework which doesn't worth learning.
However, if you want to quickly learn a new framework there are a few prerequisites that you should master first -

HTML (and what does XML means), and ideally more than simply using <div> everywhere. Imagine having a conversation to someone who only says groot".
CSS (and ideally SCSS and I would suggest putting an extra effort on https://flexboxfroggy.com/ and Grid. I guess you can also learn bootstrap but personally it feels like using "common phrases in Spanish" booklet while trying to close a million dollar deal in Latin America.Finally, of course, you should learn.
Javascript (and especially ES6, which is mostly useful "syntactic sugar" that will make your life easier, as long as you know what stands behind it). I'm very fortunate to work with javascript long enough to see its evolution from callbacks to promises and then to await/async and it really helps to understand how it works (and all its crooks) by knowing its history. And hopefully by then you're already an amazing developer and you realise that frameworks aren't magic, rather than pieces of code written by someone just like you.

Vue, just like all the other frameworks, is ultimately a templating system. Imagine having a calendar component that you can simply write in your HTML code <calendar /> and poof - the browser shows a calendar with all the logic involved. How would you write such a component? by writing some HTML code, probably some javascript and maybe some CSS and then wrapping it all together in a way that the browser can use it. Svelte and Vue lets you write all the code (HTML, JS, CSS) for your component in a single file. React uses JSX to allow writing HTML inside the JS-code and uses functional-CSS (the horror!) for its css. Angular usually (but not necessarily) has 3 separate files. The syntax might change but they're all using the same paradigm.

I took upon myself the challenge to learn Vue.js over the weekend. The live demo is available online (and its code and its XD designs courtesy of my wife). I should give credits to Coding Addict's video on building a shopping-cart. I didn't actually watch it but it inspired me to pick this project. I considered using Contentful as data-source, but decided to save time of creating 50 records. Instead I created a cake-generator. It didn't take long and it allows me to see different datasets. For longer projects, I would recommend having a consistent dataset that you can actually write tests against.Before starting to code, I double-speed a Vue tutorial course on youtube. There are plenty of them. I also watched this tutorial about the "Composition API", which is a new format to enter data they introduced and made a lot of the sample code available online not really compatible.

If there's anything I would like you to take from here is that technologies and buzzword recruiters use shouldn't intermediate you. A company's tech-stack shouldn't be an issue when picking a workplace as their two year old code is going to look old regardless. Instead I suggest aiming for a workplace that aligns with your beliefs and that you would actually enjoy working in.

Why I created a very simple photo blog generator

Oded Sharon — Wed, 13 Jan 2021 21:41:56 +0000

My wife recently picked up a new hobby of photography and decided to have a blog to journal her journey, so she went on to find a hosting service that would be: (a) easy to use; and (b) free.Surely you might chuckle as nothing easy comes for free, but we couldn't really figure out why.We tried out different platforms, such as Tumblr or Wordpress but having limited to the free version we found ourselves being unable to customise to our dream design.Understanding the needs, I also considered using a static-site generator, such as Jekyll but we realised that those normally require being able to write a MarkDown file felt like an incredible hassle compared to what we want. Why can't we simply copy the images to where they need to go and be done with it?

Intrigued by the challenge I took the time I had during the xmas break to write a simple-photo-blog app, and the basic version does exactly that - copy the files to a folder, whose name will be the post's title and run the app that will automatically upload a compiled html file. zero technical knowledge required (aside from creating folders and copying files).

As xmas break lasted more than one day, I had the time to add additional feature, such as setting publication-date or hashtags, image automated resizing and even supporting video URLs from youtube and Vimeo (by simply adding a file with the extension ".video.txt" with the link inside). I even had time to create a small demo. The code itself is also available here.

Setting it up isn't as easy as I would have liked. It still requires creating an account at some free hosting website (we used github), creating the repository and adding the "upload" command into the blog-configuration.yaml. There's plenty more room for improvement but I'm satisfied that once the system is running, it's very tech-free.

I often feel that 90% of all the content on the internet is designed for the "people who work on the internet" as the primary target audience. Many times are users required to handle HTML (or Markdown) to get something to work (such as embedding a video) or handle colours in HEX code or any other internet-jargon words (such as IP or bitrate). I think it's a shame as we're making the barrier to connectivity to the internet much more difficult for people who are already struggling while it and these people have amazing things to say or show, if only we give them the right tools to get the job done. The digital divide is a real thing and it's our responsibility as web developers and designers to bridge it.