Tuesday, June 21, 2016

OSX UX is counterproductive

In another words why I hate OSX UX. It is designed for house wives but not for professional. There are many work around but nothing given out of the box like in Windows 10. Most of ways around is to substitute what has been done by OSX.
  • In open dialog there is no space to paste the file path. Even in Xcode. Google's adwise made me hysterical.
    trick CMD+SHIFT+G opens text input for path. Unfortunately it is blank and does not match the current folder. At least TAB makes similar to bash suggestion.
  • No folder tree in finder, neither the current path. trick CMD+I opens folder preferences popup. At least here you could see the breadcrumb where the folder is located. No way to copy into clipboard though.
    hack to create a context menu for folder path. Not for ordinary people, not convenient either.
  • Functional keys so mixed with OS and application that became useless. As sample CTRL-F3 works as in application as in desktop preventing consistent behavior. Look at complains list.
  • Image editor, even primitive is not a part OSX.

Saturday, October 17, 2015

Link with embedded image

Try to click on this smile link and browser should open the new window with image but without any server connection. The image will be taken from the link itself.

Clean html version of this sample. SVG belong to wikipedia commons

How it could be used? The dynamic content created by JS to be opened as another window. Useful for printable content without server roundtrip utilizing JS and current page data.

Do you know or guess another use?

Friday, July 3, 2015

AmdHarness is capable of CDN fallback

Another phase of AmdHarness has been accomplished. This time the feature I and many folks around been asked AMD authors: to have a fall back in case the CDN is not available.
When the primary application module loader.js failed to load google CDN, the in-project copy of AMD loader is used.
Perhaps you would ask yourself: why it is needed?
The answer is simple. While there are many good CDN reason to use CDN, it is not the environment you have control on. The network could be blocked in intranet, DNS is hijacked by local government, or whatever another reason preventing CDN access ... your app will be dead because the hunt for CDN candies.
Now it is not a case anymore. Embed the AMD loader into app, but make the loader on CDN default one. Enjoy the app running from CDN when available and still serve the app when CDN is broken for client.
Links:
Happy coding!

Wednesday, May 6, 2015

Multiline text trimming with CSS

For some reason I have not found decent CSS only solution for multiline text trimming. Here is a simple and universal solution for current browsers. The height could be set to any you like, just remember to fit whole lines. Partially cut line will not have ellipsis shown properly.

Edit text and watch how the end of this text is trimmed. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Edit text and watch how the end of this text is trimmed. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Live sample

Idea by www.mobify.com/blog/multiline-ellipsis-in-pure-css

Monday, March 16, 2015

Data driven programming techniques: strength and weakness.

Data driven programming techniques: strength and weakness.

Some time ago I was able to make a whole inventory and shop application from a scratch in drastic 3 month timeframe. I guess the next time it could take 1/3rd of it. One of reasons for such speed was in the use of data driven UI and web services. The database schema was a source for web services configuration which was loaded along with the web application. Than it was used for data type operations (casting, validation, etc.) on web service level and for UI binding on front-end.

The magic is simple: each data type was presented as a read-only and writable UI widget. In such way where shown the primitive types, complex types been presented as tables with a common parent to serve a generic fields containers. It was a rare case of overriding of specific to the type functionality. Same concept of 90% web services implementation used common base functionality with adjustments only for 10% of special cases.

In parallel for same company has been made another data-driven forms framework which had a hiccups all the time. The ratio of special cases vs. reused code there was in reverse: 10% of common, 90% customization.

While both “frameworks” shown significant advantage in comparison to usual case-by-case development eventually the higher customized one started to fall apart: the development became less manageable and almost touched the same level of complexity as usual single form development practice. Looking back the many its aspects could be designed deeper which will make a better impact. But the major problem still will be unresolved: under data driven patterns in most cases the Software Development Life Cycle (SDLC) will be broken. Data driven UI usually introduced as a shortcut for long lasting case-by-case development. And as such missing many cycles, before enforced either by process or by development environment: from design (why we need a design if it is a part of metadata?) to versioning, code review up to release approval. Such systems in agile environment often developed and run in production resulting in emergencies and fast patches rather thought-through solution. Once the primary development is done it is assumed that maintenance and code adjustment will be easy, the work on changes is relocated to less experienced developers. 

Without restrains of usual SDLC it could be a disaster. So to keep it under control all parts of SDLC need to be a part of this data-driven framework. Without it the scope insulation of later changes and simple roll back process are the bare minimum.

In the inventory and shopping cart application above the DB schema was serving as metadata source for:
·         Database tables exposed as web services
·         Forms based UI
Does metadata have more use? Of course. J2EE developers immediately will recall the service flows, Object to data model mapping and many other cases, usually defined in XML files on project. Those are so deeply integrated with Java environment that people taken it as given.

I would like to bring you back to UI which modern days also taking over lot of business logic to its side. The fat client relives the server not just from the UI rendering but also serves as a gateway to the web cloud services. That is IMO Web 3.0 concept: the client is an application on its own and became a nerve cell in collective distributed network brain with server connections as synapses. The server is not in charge of whole process anymore, clients live and interact on its own discretion.

That idea defines the complexity we will face in fat client apps. The industry is trying to manage the scope by introducing so called “one page” applications. In another word by splitting the complex tack on primitive ones which do not have any or just little smarts on it. I guess that explains the popularity of AngularJS and its competitors.

But sometimes it is a good advantage to have a fat client app or module to leverage the cross-site knowledge and provide appropriate user experience. In my case the sync between version control, Wikipedia hierarchy, documentation sites and test results take too much orchestration if implemented via web 1.0 or web 2.0 patterns. The sequence of hierarchy discovery, sync data with automated and interactive merges, progress updates and error/retries handling do not fit easy into web service – UI pair. Old dogs would advise to look into server-side model with live sync like IceFaces or Vaadin. Modern ones will refer to MeteorJS. While that could be doable (not sure) the idea of keeping live model on server side is hardly scalable. Few hundreds simultaneous sessions will need proportional resources increase on server side. Rather the fat client will use just a bare minimum from each involved server.

Programming of complex apps is not easy a priory, on front-end especially. The XHR chain for the described tack with complex hierarchical orchestration is impossible with usual callbacks: too many of them will be encapsulated into each other. The deferred pattern given a bit more flexibility on scenario creation. At least sequential chaining is a part of when().then()

Such pattern could use a help from frameworks. Dojo Toolkit given the deferred collection (dojo/promise/all); some essential deferred combinations you could build yourself (like the dynamically added dependencies during hierarchy traverse via XHR). It still will be the hardest challenge to read and maintain such code. Not to mention to give such to third party developers for own modules integration.

The data driven flow will be the answer for resolving of complexity above. It matches the aspect oriented or reactive programming principles: the model change is handled by small and discrete actions. You could name it data change event handlers if that is easier to understand. In such case the flow will be defined by current data state. This state could be preserved and recovered at any moment giving ability to develop and test the small steps independently simplifying the development.

The decision on what form the metadata presented is on you. Handy part for it would be the hierarchy query, ability to persist/(de-)serialize, mix and separate different data aspects on same level of hierarchy( aka namespaces), change event subscriber API. Guess what has been chosen by XML guy J

Happy coding!

Wednesday, March 11, 2015

Web 3.0?

Modern days web page is also taking over lot of business logic to its side. The fat client relives the server not just from the UI rendering but also serves as a gateway to the web cloud services. That is IMO Web 3.0 concept: the client is an application on its own and became a nerve cell in collective distributed network brain with server connections as synapses. The server is not in charge of whole process anymore, clients live and interact on its own discretion. That idea defines the complexity we will face in fat client apps. The industry is trying to manage the scope by introducing so called “one page” applications. In another word by splitting the complex tack on primitive ones which do not have any or just little smarts on it. I guess that explains the popularity of AngularJS and its competitors. But sometimes it is a good advantage to have a fat client app or module to leverage the cross-site knowledge and provide appropriate user experience. In my case the sync between version control, Wikipedia hierarchy, documentation sites and test results take too much orchestration if implemented via web 1.0 or web 2.0 patterns. The sequence of hierarchy discovery, sync data with automated and interactive merges, progress updates and error/retries handling do not fit easy into web service – UI pair. Old dogs would advise to look into server-side model with live sync like IceFaces or Vaadin could potentially do. Modern will refer to MeteorJS. While that could be doable (not sure) the idea of keeping live model on server side is hardly scalable. Few hundreds simultaneous sessions will need proportional resources increase. Rather the fat client will use just a bare minimum from each involved server. Happy coding!

Sunday, November 2, 2014

AMD global require and relative path from HTML

In my environment there are lot of tests and templates are HTMLs with self-testing functionality. To make them path-agnostic I was using relative MIDs to same folder resources: scripts, templates and CSS.

ModuleFolder

  • MyModule.html
    • require(["./MyModule"],function(MyModule){ new MyModule({},createDivInBody() ).startup(); }
  • test/test.html
    • require(["../MyModule"],function(MyModule){ new MyModule({},createDivInBody() ).startup(); }
  • MyModule.js
    • require(["dojo/text!./MyModule.html","AMD/cssI!./MyModule.css"],function( template, css) {... }
  • MyModule.css
As dojo AMD and perhaps some other AMD implementations disrespect relative path on global require I need  either to work around or make AMD working as expected. By expected I mean not imaginary potential use of absolute path but real life expectation when looking on the code sniplet above.

There are 2 bugs exposed in the code:

  1. The repative path in HTMLs is treated not as module with JS extension assumed but rather abstract resource, so no JS extension added when path converted to URL. What it could be if not a JS and why there is a difference to MID ?
  2. In CSS plugin the relative path is not working either. It is computated relatively to dojo basePath
The bug fix is not an option(see bellow). What could be done?

  1. Shim the require() and rebase relative pathes with regard to existing basePath
  2. Create artificial "currentPage" package and place into require config, replace relative path dots with this package: require({paths:{currentPackage:location.href... }},["currentPackage/MyModule"]
  3. Use absolute package name: require(["lib/MyLib/PackageX/MyModule"
  4. give up on dojo and use another AMD loader
Perhaps someone could give a better suggestion which is quite appreciated.
If there is a solution, please share.

Regards,
suns

PS. Thank  Christophe Jolif's wisdom for this pain: https://bugs.dojotoolkit.org/ticket/14649
PPS. for interested will keep track on my blog.