Profile cover photo
Profile photo
BriteSnow
41 followers -
Building Enterprise HTML5 Applications
Building Enterprise HTML5 Applications

41 followers
About
BriteSnow's posts

Post has attachment

Post has shared content
Understanding #java8 Stream Collector By Example.

String Joiner with trimming using java 8 custom collector:

Here are some questions I got from someone and I wanted to share the answers with everybody. 

Q: What is the differences between snow.jar vs brite.js

snow.jar and brite.js are two independent technologies that happen to share the same philosophy of being lightweight and close to their respective environments. 

brite.js is a HTML/JavaScript library that brings a lightweight DOM centric MVC to HTML. Contrary to Sencha, Angulars.js and many other high abstraction MVC JavaScript frameworks, brite.js just add the strict minimum to the DOM to make it a robust and scalable MVC environment to build highly interactive application in a scalable manner. Meaning, it does not try to bring a meta-binding language or make everything a widget with over killed inheritance, but rather, give a fully asynchronous lifecycle for bigger component (composite views) while encouraging to use native HTML/CSS and event delegation for smaller elements (e.g., buttons and list items). The key API of brite.js is brite.registerView and brite.displayView. 

Snow.java has the same philosophy than brite.js but on the server side with Java. Snow is a Web Binding frameworks based on Guice with a efficiently, lightweight, and extremely flexible way to bind HTTP request to Java methods for WebREST api or SEO based HTML pages use Freemarker as a templating engine. Contrary to Spring, snow.java does not intend to solve all common problems neither think that a single framework should do so, and promote targeted libraries or micro framework rather than big mega frameworks a la Spring or JEE.

Q: My app uploads and display images, integrates with aws s3 and aws rds. I'm using mysql-stored procedure for all my dao

Snow and its approach are perfect for this use case. I would create my own DAO scheme that rather to use the Snow embedded Hibernate facilities, I would create by own DAO hierarchy with a DAOHelper that would have the lower level DB APIs that your Dao would use. 

I would have a @Provide DAOHelper in the AppConfig.java (the Guice Module) which will create the pooled DataSource and initialize the DAOHelper (this will be a @Singleton), and then @Inject DAOHelper in my Entity daos that would also be @Singleton. 

For your image upload, just do a @WebPost that and have a @WebParam(…) FileItem fileItem, and you should get the file uploaded. A while back I also added the ability to add multiple files with FileItem[] fileItems from a user’s request (let me know if it does not work). 

Also, one cool thing about the way Snow properties file, is that you can have your default properties in the /WEB-INF/snow.properties, which will point to your development mysql and all, but then, when you deploy you can override any properties by putting a files name [appfoldername].properties in the /webapps/ folder. So, let’s say your application is name “coolpix”, then you would have: 

/webapps/coolpix/ (war folder)
/webapps/coolpix.properties (any properties in this file would override the default /WEB-INF/snow.properties)

This is very simple but very flexible. 

Post has shared content
Interesting article about some of the MongoDB pitfalls.

The trick with MongoDB is that there are lot of buzz and it is hard to get down to the real benefits beyong "SQL is bad" and "JSON is great". 

Post has shared content

Post has shared content
brite.js 1.1.2 released
https://github.com/BriteSnow/brite#112-march-22nd-2014

+ added brite.config.jsPath and brite.config.cssPath for configuring the location of the brite view components when using on demand loading
. updated examples to jquery 1.11
. minor reformating to be more jshint compliant. Updated to bootstrap 3.1.1
. update to handlebars 1.3.0 and fix taskmanager with latest bootstrap
+ Makes brite.js compatible with AMD and CommonJS (Thanks to Sankar Gorthi)
. updated sample/taskmanager to point correctly to the bootstrap 3.0 and use handlebars-1.0.0
! remove the brite.gtx (canvas utilities) from brite (moved gtx.js to /extra)
- btap issue when binding only on parent, btap on child does not propagate
- Fix btap event to fire only once (without the use of preventDefault which would be too destructive for other event handlers)

Post has attachment
#HTML5 Nice intro to #WebComponents via ShadowDOM

Post has shared content
Snow update on the 2.0.3-SNAPSHOT (see http://britesnow.com/snow/maven)

Big thanks to evanj and imranzahid01 on GitHub for their pull requests. 

Commit summary (notations: + addition, * major, ! API change, . minor): 

+ Added Convenient SnowTestSupport.doGet, doPost, doPut, doDelete, doHttp methods.
* Removed JUnit dependency from SnotTestSupport (i.e. Now SnowTestSupport is test framework agnostic, just extend it to make it play with your unit framework)
. From added minor pom.xml update to support JDK 1.7 on Mac
. Cleanup some Logger and printStack...
. Call SnowTestSupport.shutdownWebApplication in SnowTestSupport.initWebApplication (making the @AfterClass optional)
! Moved SnowTestSupport.assertContains to test/java/.../AssertUtils.assertContains

Post has shared content
My take on Angular.JS and others High-Abstraction-Frameworks:

I understand the attractiveness of AngularJS (comes from Google and do some DOM black magic), however, I really think it is the wrong approach for building real HTML applications. It tries too hard to make the DOM what it is not, and at the end day it distracts developers from learning what really matters, HTML, JS, CSS, and the DOM, because frameworks come and go but HTML/JS/CSS will stay. 

While GWT had a totally different approach, Angular.js and GWT suffer from the same symptoms, high level of abstraction, vilifying DOM programing for application, very complex internals, and at the end of a project developers will have spent a huge amount of time learning the framework's intricacies (for Angular.js, the infamous directive model) rather than native runtime environment which is in this case HTML/JS/DOM/CSS programming. 

On MVC & HTML

Contrary to what many framework developers like to say, I think the DOM can be a very powerful and flexible environment for scalable MVC application development. Developers should just stop trying to bring traditional MVC model to the DOM. The DOM has a different level of primitives than any other runtimes (e.g., Win32, Java, Flash-Flex, iOS), and trying to bring other MVC models (MFC, Swing, Flex, Cocoa) to HTML will always result in un-optimized and over-complex frameworks and application model. 

Developers should learn how they can change the way they approach MVC to adapt it to the DOM way of thinking (e.g. decoupling rendering from behavior, using delegates over direct binding, using the DOM event model for Application eventing, …). By doing this, developers will learn what matters most, HTML, JS, and CSS, and the DOM, rather than the framework of the day (or the year)

My Advice to Developers

So, if I have one advice to developers, is to not be afraid HTML/JS/CSS and the DOM. This is the best investment you can take. Frameworks come and go, HTML/JS/CSS stays. Using libraries to be more productive is great (handlebars, jquery, bootstrap, ...), but using mega-abstraction-frameworks that does black magic will distract you to learn what really matters, the native language and runtime environment, which in this case, is the DOM (HTML, JS, and CSS). 

In other words, do not code C++ as you code C, do not code Java as you code C++, do not code JavaScript as you code Java, do not do Swing in HTML, do not do Flex in HTML. Learn the runtime environment and adapt to it, and avoid anything that does black magic. 

And the most important advice to Application developer stop believing that framework developers knows more of what you need that you do. Focus on your native environment, use library over frameworks, and always. Use focused, independent, well-thought libraries that solve couple problems very well, rather than mega abstraction framework that try to solve all common problems a developer might have. For example, use Handlebars, jQuery, Bootstrap over Sencha or Angular.js in the HTML/JS/CSS world, and Google Guice over Spring on the server. 

In very short, my mantra when building a modern, flexible, and future-proof tech stack is library over framework


Linked (http://lhorie.blogspot.ca/2013/09/things-that-suck-in-angularjs.html) is a good article on things that sucks on Angular.js by an Angular.js developer. Do not get me wrong, the Angular.JS team is extremely smart, as the GWT team was, but just that there is just too big of a mismatch between what the DOM is and what Angular.js is trying to make it to be. 

Post has attachment
Finally updated the G+ BriteSnow logo.
Photo
Wait while more posts are being loaded