Load the browserstack.com local tunnel with a .bat file

We are using browserstack.com for our testing on the current project – real IE8 is very different to IE8+ in IE8 mode

Anyway I am lazy (efficient) so I created a batch file to run and create the local tunnel. Take the following and add it to a .bat file (windows only of course) and run it when you are logged into the browser stack – this may change based on your JRE install path

bs2

 

cd C:\Program Files (x86)\Java\jre7\bin
java -jar BrowserStackTunnel.jar *YOURKEYHERE* your.localserver.com,80,0 -force

 

bs1

SSJS JSON parsing part deux

Yesterday’s blog post about adding json2.js created a discussion on it’s use and Johann pointed out that¬†there were already JSON parsing functions baked into XPages SSJS. Phil Riand added them back in 8.5.1 and it has actually been mentioned a number of times on various Blogs. So apologies to all for me not knowing about it. I guess I never bothered to look as I knew how to do it with the json2.js ūüôā

Julian Buss added a wiki post about it years ago –¬†http://xpageswiki.com/web/youatnotes/wiki-xpages.nsf/dx/Work_with_ServerSide_JavaScript

	var json = toJson( {a:[1,2,3]} ) //-> '{"a":[1,2,3]}'
	var jsObj = fromJson( '{"a":[1,2,3]}' ) //-> {a:[1,2,3]}
	isJson( '{"a":[1,2,3]}' ) //-> true

So ok I learned something new – happens a lot – but then I also got to thinking – as I mentioned yesterday JSON.parse and JSON.stringify are so ubiquitous I decided to write some code to minic the coding standard in SSJS. This code serves zero purpose other than to make the usage of JSON consistent between SSJS and CSJS. It is a short version of what I wrote about yesterday and does not require the addition of the json2.js to the database.

	if (typeof JSON !== 'object') {
		JSON = {};
	}
	JSON = {
		parse: function(str){
			return fromJson(str)
		},
		stringify: function(obj){
			return toJson(obj)
		}
	}

Safe JSON parsing in XPages SSJS

JSON is now ubiquitous in the world of JavaScript and the origins can be found a http://www.json.org/.

Douglas Crockford was very concerned about using eval() to convert strings to objects and so he created  json2.js which can be found here https://github.com/douglascrockford/JSON-js/blob/master/json2.js. If you look at the code there is a huge RegEx in the middle of it which purposefully ensures that there is no dangerous code which the eval statement is run on. You should read the comments in the code Рvery insightful !

All browsers (IE8+) now support JSON.stringify or JSON.parse by default and we no longer need these functions to be added as an external library.

I found however that XPages SSJS does not seem to recognize the JSON object. So I added the json2.js code to an SSJS library and then added it as a resource within my XPage.

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
	<xp:this.resources>
		<xp:script src="/json2.jss" clientSide="false"></xp:script>
	</xp:this.resources>
	<xp:repeat id="repeat1" rows="30" var="rep1">
		<xp:this.value><![CDATA[#{javascript:
			var temp ='[{"name": "marky"},{"name": "Billy"},{"name": "John"}]'
			return JSON.parse(temp)
		}]]>
	</xp:this.value>
		<xp:text escape="true" id="computedField1" value="#{javascript:rep1.name}"></xp:text>
		<hr />
	</xp:repeat>
</xp:view>

And with this I am now able to take a string of text – convert it safely to a JSON object and then use as the source for my repeat control.

json1

This message was inspired by Tim’s Tripcony’s blog post.

I love the idea of storing data as a JSON string inside of a single notes document field. This would move using Lotus Notes closer and closer to a modern NoSQL system, making applications more and more portable – love that idea.

However Рthis renders searching by field useless Рwhich is usually one of the  requirements of an application.

1291: EXTJS in XPages: Modernizing IBM Notes Views Without Sacrificing Functionality

I am very happy to announce that I have been accepted to speak a second time at IBM Connect this year !!

In this session I am going to quickly review some of the previously published EXTJS related items on the blog (apparently not everyone reads it) but more importantly I want to discuss user experience. If nothing else, I have learned over the last 18 months that not only is EXTJS very cool in loading thousands of notes documents into ¬†usable and functional web based grids, it also demands a serious serious respect and insight into the user experience. If your user’s are willing to wait many seconds to load thousands of documents they will not be willing to load thousands of documents again, and again, and again, as they go to view each individual document and go “uuurgh, not that one” and then reload the web page.

But this is XPages, and we have the technology to do better with a little forethought and planning. There is a monumental difference between:

1. Being able to meet a requirement to load thousands of documents into a grid and allow the user to open and review each document

and

2. Making them not hate the application in meeting requirement 1

(By the way – requirement 2 is never written in the same document as requirement 1 – it is kinda assumed)

 

Come and see the session, I promise it will be entertaining, there will be lots of demonstrations, stacks of free code and you will be able to relate to issues and requirements which you will have come across when modernizing IBM Notes applications.

 

The Abstract

In this session Mark will demonstrate how the use of the EXTJS library can effectively meet the requirement to modernize large data applications without sacrificing user interface familiarity. EXTJS is the only grid framework with large data set optimization built in.
Mark will discuss and provide working examples of how to manage large data sets and with it an exceptional user experience. You will learn how to display 1000s of¬† documents through XPages in ways previously considered impossible. With user customizable features like REST service integration, categorization, sorting, searching, column totals, filtering, charting, exporting to excel and many more you can put the power of instant data management back into a web user’s hands.

Discovering Page Audits in Chrome Dev tools – apparently I am bloated !

I came across a “tooling” presentation by Addy Osmani¬†which is mostly not relevant to XPages development but in there I saw a nugget about Page auditing within Chrome Dev tools. I am staggered about what I found about the site I am working on site and apparently I need to learn more, quickly……….

Bring up the site and open Chrome dev tools

ch1

 

And then after running it – WOW…apparently I could be doing a better job in here…..

ch2

I have no idea if I can do anything about some of these – but some I definitely can and if it makes for a faster website load time then it can only be a good thing.

ch5

jQueryUI I can definitely make smaller because you can do custom builds of the functionality you need – I need drag and drop, sortable and accordion.

Bootstrap – I think I am stuck with although according to the presentation grunt-uncss looks promising!

Font-awesome – do I REALLY need it for 3 icons? Maybe I don’t now I look at it !!

The rest are used in this single page app – just not right on the front page

ch3

I could combine the CSS and JS files using XPages application properties – but it breaks when I do that. Some manual combining could be done.

ch4

 

“Always include external CSS files before external JavaScript” – I did not know this – good to know and these are all in the XPages theme so might be able to reorganize – unfortunately with dojo always inserted at the top of the page I do not know if that can be overcome – I think so…..

 

I will make some changes and post an update in a few days to see if there is a noticeable difference in page load speed. When developing I always have cache turned off anyway so I will be able to tell if the pages load faster.

 

Louis Richardson – Leverage Social Collaboration to Drive Business Results – Dec 9th DCLUG

DCLUG is very excited to co-host Louis Richardson who will be in Washington DC December 9th to speak about Social collaboration

I saw Louis speak at MWLUG 2012 and I can attest to what  great engaging speaker he is. He is able to distill a concept into a presentation and not make it sound like a sales pitch. The capability speaks for itself, what you need to understand is why you need to use the product, not primarily what the product will do for you.

For more on Louis, check out his site –¬†http://about.me/louisrichardson
I serve as an IBM Worldwide Storyteller & Enthusiast covering Social Business and Smarter Workforce topics”

Date: December 9, 2013
Time: 1:00PM ‚Äď 3:00PM Eastern
Location: IEG Briefing Center
600 14th Street, NW
Washington, DC 2000

Business at the Speed of Expertise: 
Social technologies are helping people connect, communicate and share information. Communication & Collaboration have become a commodity thus tactical РCoordination & Social Collaboration have the most value thus a more strategic direction. Once you have Embraced Social Collaboration, you can Extend your current solutions and finally Consolidate.

The Result: Single Strategic Platform of All Capabilities. Social Collaboration Capabilities can be INJECTED into Cloud, Mobile, Big Data to provide a secure personalized contextual multi-channel experience.

See the flyer

For more information please check out the DCLUG Meeting site –

http://www.meetup.com/DC-Lotus-Professionals/events/150295112/

YOU MUST REGISTER for this event – see the link below

Register for the event with IBM – seating is restricted to 50 people so you MUST REGISTER HERE

Accepted to speak at Connect 2014 – With John Jardin

Words cannot describe how excited I am to be speaking at Connect 2014 with my very good friend John Jardin.

https://www-304.ibm.com/connections/blogs/socialbusiness/entry/connect_2014_sessions%3A_this_list_is_getting_longer%21?lang=en_us

IBM Worklight: Going From XPages Mobile to Native Mobile Applications, John Jardin, Ukuvuma Solutions; Mark Roden, PSC Group LLC”

We are very excited to be talking about IBM Worklight and how any XPages developer currently creating mobile XPages already has all the skill set necessary to create native mobile applications with Worklight.

We decided over a beer (or maybe more) in Orlando¬†last year¬† that we wanted to speak together but the question was on what…. The plotting and hatching of a plan started for real mid-year. We knew it had to be about mobile, but exactly what that entailed evolved over time and more than 10+ draft abstracts.¬†John showed me Worklight a couple of months ago and I was hooked / fascinated and excited about easy he made it look to work with.

John is a massive contributor to the XPages community and is an IBM Champion – I am honored to be sharing the stage with him and I know we are going to rock the house with this presentation.

More to come over the next two months ūüôā

Things you learn about localization in XPages – french script tags

In the current project I am working on we are using localization to allow translation into other languages. For more on localization check out this wiki entry

Much to my horror I found out yesterday that <script> tags are translated – as if it was just text on the screen.

<script>
	alert('hi Marky')
</script>

when localization is turned on for French looks like this

<script>
	[fr| alert('hi Marky')]
</script>

and funnily enough that causes problems in your code.

The reason it does this is because by default localization translates any text on the page and creates the appropriate properties file tage for it in the database – this is very cool when you want it to be, and apparently very annoying when you don’t. Localization clearly does not see any difference between <script> and <div> on the page for this purpose.

To correct this issue. you need use the computed output script instead.

	<xp:scriptBlock id="scriptBlock1">
		<xp:this.value><![CDATA[
			alert('hi Marky')
			]]>
		</xp:this.value>
	</xp:scriptBlock>

Nov 21st – DCLUG – Managing large data sets in an XPages application

Next week I have the privilege of speaking at DCLUG again. This time discussing EXTJS and how to manage large data sets in an XPages application.

For more information and to sign up for the meeting please go here: http://www.meetup.com/DC-Lotus-Professionals/events/150317872/

Date

November 21st

Time

11:00-11:30 Networking/Lunch

11:30-12:30 Presentation

12:30-13:00 Networking/Close

Abstract

Moving notes client views to the web has always been a challenge. Out of the box XPages provides us the viewPanels and Dojo Data Grids which do a decent job of getting the data to a user, but it not an optimal user experience. Clicking next 25 paging through 3000 documents is not ideal.

With large data set management built in and user customizable features like REST service integration, categorization, sorting, searching, column totals, filtering, charting and many more, EXTJS grids give us the ability to put the power of instant data management into a web user’s hands.

Mark will demonstrate and provide examples of how the EXTJS library can be used to effectively meet a requirement to modernize large notes client views (1000s of documents at the same time).

 

Lunch will be provided for attendees by IBM

Future-proofing yourself.

The other day I got an interesting comment on an old blog post of mine and I felt like it really deserved a separate post in response rather than being lost in the comments. This is a personal assessment of my skills and the need to future proof myself Рit is not a sermon Рjust personal musings which will hopefully inspire.

The Comment

I have copied the comment here for context.

The past several months, I’ve been working on many Notes client applications, but now we’re ready for a big web based application! So, back to jQuery (YAY!) and some dojo (boo!).
Outside of the XPages world, it seems that jQuery is overtaking everyone else. In fact, I heard that the next version of javascript is taking elements of jQuery! I remember there were Mootools, Scriptaculous, Prototype and TONS of others over the years! Just check the stats of how many Stackoverflow questions there have been for various js librairies: http://stackoverflow.com/tags. It’s not even close!¬†So, for the sake of argument, what if dojo shuts down within 3-5 years, and only Xpages are using them. Then what?

From the outside world, it just seems that jQuery is the better long term decision. Any thoughts?

The Answer(s)

So a couple of things to address directly from the comment:

  1. IBM is a significant contributor to Dojo and has been for many years – I think it is unlikely to “shut down”
  2. jQuery may be “the world’s most popular JavaScript library“, but who’s to say it will be that in 3-5 years? In terms of the internet that is a lifetime away.
  3. JavaScript is an evolving language and of course it will take into consideration any techniques and desires that the development community wants/needs. IFRAME, AJAX and parts of the HTML Spec which we take for granted today were invented as IE only tools which make it into the spec (yeah Microsoft was really groundbreaking in some senses)
  4. I do not agree that jQuery is a better long term decision – I think it is a much better “today” decision and probably at least the next couple of years decision – but what is “long term” anyway? ūüôā
  5. Learning the fundamentals of JavaScript I believe is the best long term decision and then the actual library becomes much less of a conversation.

So What?

So I really take the original question as one about future-proofing yourself rather than XPages specifically. For those of you who have already taken the plunge to XPages you have already “evolved” your skillset and you have almost certainly learned new skills (like them or not). Really that is what is important is the adaptability of your skillset – not what should I learn today and what should I be ready to learn tomorrow.

So having learned XPages, what is the hardest thing you have had to learn? For me it is all of the server side controls and the JSF component model. It still causes me mental heartache today and probably always will. I am sure it is obvious to anyone who regularly reads my posts, I am much much happier in the user interface, Client Side JavaScript is my thing, it always will be. I am content that that decision will not harm my future work prospects.

Future Proofing Marky

So for me future proofing myself happened the day I realized that I had been “programming JavaScript” for over 10 years but I had not been a “JavaScript developer” for any of it. If these terms are not familiar to you then you are also not a JavaScript developer: closures. object literals, prototypal inheritance, callback functions, IIFE.

So I set out to learn……and jQuery helped me do that. But……..

There are people who believe that jQuery is an unnecessary safety blanket used by people who do not really understand the language. They also believe that jQuery encourages people to be able to program websites using plugins while they understand very little of the underlying concepts. To that I say *crap*. I do not understand how C and C++ work but I use an operating system and developer tools written in those languages – is anyone fussing about not knowing that? I think not.

My point is, that learning jQuery itself will not teach you to be a JavaScript developer – but it most certainly can help.

  1. The code is free and easy to read – the non-minified version is well documented, easy to read and well laid out
  2. There are many blog posts on how does jQuery work (this is the funniest)
  3. You owe it to yourself to better understand web technology. It is not going away. You may as well start using the tools and understand them as you go along.

I am not saying you must learn JavaScript or you will fail as a developer – far from it. But I will challenge anyone who thinks they are a web developer and is not a JavaScript developer then you are fooling yourself.

JavaScript is not only restricted to web development. As we all see in XPages it is also a server side language and in node.js the fastest growing server side technology for web application development.

Conclusion

So for Marky, JavaScript is the obvious choice. It is not Java, it never will be for me, and I am happy with that decision. I am also convinced that my action will determine my fate. I will not wait for fate to tell me what to learn after my job no longer exists.

The conversation shouldn’t be about what is the best library to use for the future but what skillset do you need to be able to adapt. If you build web sites then JavaScript has to be the way to go.

Web technology moves on a <2 year cycle – welcome to the future of constant re-invention of your skillset if you want to remain relevant.

For your own sake, make yourself better and more flexible – you have no one else to blame if you don’t and the worst happens.

For the record

If XPages is no longer in 3 years what will you do? 2.5 years from now will not be the time to figure that out.

I have no evidence or reason to believe XPages will be going away any time soon ūüôā

Dojo is a fantastic JavaScript library. It was never designed to make sexy websites, it was created as a framework for application design. XPages is a fantastic example of how to use Dojo to build a framework – well done IBM.

jQuery is not intended to build “websites”. It is intended to help in the development of websites and simplify the developer experience through standardized functions and removal of browser dependencies.

Ember.js, Angular.js, backbone.js and many others are the new, modern “today” libraries for architecting websites. MEAN is the new¬†LAMP¬†stack and if that all means nothing to you – you should at least do yourself the service of some reading.

Sheer coincidence that I saw this from¬†Tim Tripcony today¬†– same deal – different perspective – same conclusion (metaphorically speaking) ūüôā