XBox IE and Angular dynamic styles

Some errata for you:

I was testing an application across some tablets, laptops and phones, and found some of the usual required UI tweaks to make bootstrap a little more cooperative and so on, but this one I just ran into and it seems particular to IE on XBox, which I tested just for the heck of it.

I had coded up the styles inline to get it right before moving it to CSS; this was just me working through it quickly, so I know that the second way here is more correct, and that switching
on the ng-class is typically preferred.

If you set a style dynamically this way, it won't work (only on XBox IE):

<div style="padding-top: 1px; 
background-color: {{ colors [ data.colorname ] }}">

If you set it this way, it will

<div ng-style="{ 'padding-top' : '1px',
'background-color' : colors [ data.colorname ] }">

The peculiarity is, whether or not it should be done this way, the first one works everywhere, on every phone, tablet, and laptop I had available to check it on (two macs, two PCs, two phones), but the background color did not render on XBox IE.

I changed to the second form and it worked fine.

Again, just some errata.

As always, thanks for visiting.

Acronyms in Angular Directive names

Here's an interesting quick one.

Many industries live and breathe acronyms. So, it would be no surprise if they wanted to use them in directive names.

Say you were creating a management system. PM is a pretty standard acronym for Project Manager.

If you name your directive this:

myorg.abPMDirective

Then what you might expect, with Angular doing its funky "you wrote it this way but we'll divide it up with dashes this way" thing:

ab-pm-directive

Nope. You will have to use it like this as a directive (assuming attribute restriction in the directive itself):

ab-p-m-directive

Or, rename the directive:

myorg.abPmDirective

Angular evidently does not recognize all-caps acronyms. Certainly not a deal breaker, but I'd like to think that if I was building out that mechanism within Angular I'd have thought of this one.

If there is a solution to this that is very straightforward and uses the framework as-is, nobody I asked is aware of it.

Yes...I am aware of the documentation and spec for this. My point is that a little case detection in the mechanism could solve it. Perhaps a good interview question.

There is also no debug error of course. One of the frustrating things about using directives is, any typo and it just won't work, but nothing will tell you why. A test can fail, but it won't tell you that you declared the markup incorrectly or that the directive didn't start up (why would it). It's one of those sort of old school "you just have to know" things. Ultimately you could probably write a test to figure that out but...well, I don't have all day to toy around with creative tests.

As always, thanks for visiting.

Getting an Entity By ID: Google Datastore (using Scala)

Here's another one of those, "it should be so simple" ones.

If you store an Entity in the Google Datastore, and you want to retrieve it by the auto-generated "Long" ID, none of the things you think would work...work.

SELECT * FROM mytype WHERE id = 12345, and so on...fail.

Note that the auto-generated column where the ID is put, is actually shown as "ID/Name" (but using that in any form doesn't help either).

You have to work with a Key (the below code assumes you have already created a new Query instance):

Note that I make sure I convert myVal to a Long (these two lines of code are actually in a "match", which via map iteration checks if the "v" in ( k, v ) is a Double, so I'm guarded against the exception you may have balked at), because when I send over the JSON from the UI, it appears as a Double on the server side, which won't work (and I tried everything short of getting into custom serialization).

Anyway, I banged around a couple of hours on this one, maybe it saves somebody some grief.

As always, thanks for visiting.  

Scala: Get Google DataStore PreparedQuery Entity list, convert to JSON Array

This was an interesting one. Using Scala, I had to do something pretty simple with some stored Entities in the Google DataStore:

val query : Query = new Query ( "mytype" )
val pq : PreparedQuery = datastore.prepare ( query )

"pq" now contains an iterable list (either as an iterator or a java list), of Entity objects that are "mytype". Great, the datastore is really easy to work with...but I need JSON.

If you just "toString" these lists, you get a lot of "->" symbols and such, that of course aren't JSON. But without excessive iteration, matching, implicit conversions, and so forth, how can I just take that list in "pq" and somehow transform it into JSON?

It turned out there's a great utility, JSONArray ( val : List ). It will turn a Scala list into a nicely formatted JSON Array. Note that it will NOT transform the entities, you have to do that separately (as you'll see, fortunately it's simple).

The tricky thing was, that the List returned from the PreparedQuery isn't compatible with that JSONArray constructor, because it's a Java list (as opposed to a Scala one).

So, for the heck of it, I tried this, and it compiled...but didn't run.

new JSONArray ( pq.asList ( withLimit ( 1000 ) )
.asInstanceOf[List[Entity]] )

The error was that a "LazyList of type java. (etc. etc.) can't be cast to immutable Scala list". Including JavaConversions and so on didn't work. At runtime, the code would break.

I figured there is probably some way around this if I kept researching and experimenting; I went through my Scala book, Stack Overflow and so on, and found/came up with a variety of different ways of mapping and moving around the entities in the lists. Some of it even ran, but nothing seemed stable under all conditions unless I wrote a lot of edge case code. I was moving away from a "keep it simple" answer which I could easily rework if I found a clearly better solution.

So I came up with this, and it worked for everything I threw at it. Iterate the Java list using the asIterator returned by the PreparedQuery, pass each item to a new JSONObject, and add that JSONObject into a Scala ListBuffer (a very nice "in progress" list utility). Then get the ListBuffer.toList and pass it to JSONArray...viola, all entities (and their properties) in the PreparedQuery entity list are now a JSONLint worthy JSON array.

Note that in my Entities, I store either simple values (strings numbers etc.) or valid JSON objects. So I don't have to worry about nested collections; if you do, you might have to do some recursion and matching/transforming here. Not rocket science but a higher order of complexity...I recommend just storing JSON or basic values if you can.

Notice I use a ListBuffer, which creates an "in progress" list that you can append (as opposed to an immutable Scala List or fixed dim Array). Later, ListBuffer is submitted to JSONArray as a plain old Scala List.

Anyways, here's the code:

When I catch the response.write of this in my JavaScript, all the JSON is fine. As always, thanks for visiting. 

How To: Use JavaScript/JSON object in Scala Servlet

I'm relatively new to Scala. I really like working with it, far more so than Java. Straightforward callback functions, and processing instructions fed into course-grained iterators and so on (which tends to lead toward higher-order factoring instead of lower-order sub typing), are really a better way to program imho. Not to mention traits, mixins, and other such nerd fun.

It's not always easy though. One such area is JSON.

JSON isn't supposed to be ponderous to work with. I should be able to do something like this...

> Get JSON string
> Turn it into JSON Object (or from object into string)
> Easily access a key->val.
> Turn the whole thing into a string

...with a couple of lines of code.

I've looked through a number of approaches. The examples I've found using the "native" Scala JSON utils tend to be ponderous (write a wrapper class that goes through opts and matches against...), or, you end up chasing down a third party library. I have no issue with third party libs, but I do believe that if the language/environment does something important natively, you should know how to use the basics of it, and I am indeed trying to do something very basic.

Anyway, I worked through java immutable map to scala immutable map conversions and everything else people are trying to work around, and landed on this amazingly simply routine. Note that I couldn't say for sure if this is the best way under all conditions, but it's working flawlessly for me (I'm building an app on the Google App Engine using Scala).

I'm sending a very basic JSON object from my JS front end using JQuery.post, it has two keys, and one of the vals is a nested object (which can of course have other nested objects etc. as long as it's all valid JSON):

{ "dstype":"registration","dsdata":{"val1":0.5,"val2":"Hello"}}

I get it in the servlet's doPost method, and access like this. Note that yes, I'm aware that the req.getParameterNames.nextElement isn't semantically pleasing. But it returns exactly what you want, which is that incoming JSON data. And I've omitted exception handling for brevity:

// The objects I'm using, sure you could just ._ but let's get specific here
import scala.util.parsing.json.JSONObject

import scala.util.parsing.json.JSON

// gets the JSON string. I know it looks a little odd,
// and there's hopefully a more semantically and equally brief way to do this,
// but this returns the JSON as posted by the front end, and that's what I need.

val jsonString = req.getParameterNames.nextElement.toString 

// parses it into object Some(Map( k -> v, k -> v,  ... ) )

val jsonObject = JSON.parseFull ( jsonString ) 

// gets the value of "Some" from the jsonObject, which is the map you want

// note that this can throw a propertyNotFound exception if there is no value

val jsonVal = jsonObject.get 

    

// matches against type to run desired typed arguments,

// for example, here execute takes a String Map Any,

// or if you don't like infix notation, Map[String, Any],

// We can't just pass in jsonVal, there's not enough type info.

// Note that you could also use jsonObject.get.instanceOf[String Map Any],

// but as I understand it, casting is frowned upon in Scala in favor of matching.
// I never liked the Java way of casting around map, which forced you to put 

// in the RepressWarnings attribute, so I'm going with the flow. 

jsonVal match {

    case m:Map[String,Any] => new MyCommand ( ).execute ( m )

}

That's it, execute now gets a String Map Any (or Map[String, Any] if you prefer), which you deal with as a usual Scala map. 

Note that what I actually do, is pass a callback to execute as a partially applied function. Partially applied functions are very cool.

case m:Map[String,Any] => new MyCommand ( ).execute ( m, onMyCallback _ )

execute looks like this:

 def execute ( params : String Map Any, 
               callback : (String Map Any) => Unit ) = {}

In the command's execute class, when all is done, I pass the result to the callback, which executes and writes the response to the client. Note here (remember I'm back in the servlet now via the callback), I just use a new scala JSONObject ( response ).toString( ) to serialize the data. 

def onMyCallback ( data : String Map Any ) = {

      var response = Map[ String, Any ] ( )

      response += ( "status" -> "ok" )

      response += ( "data" -> "MyServlet - Command executed" )

      resp.getWriter.print ( new JSONObject ( response ).toString() )
}

Anyways, all this finally let me stop noodling with Scala json code and get down to the business of finishing up my project, which I have to do somewhat quickly so I can get back to the paying work.

As always, thanks for visiting. 

AngularJS Simple Noob SPA

(Note: Link to the doc is at the bottom of this post).

I've been working on really formalizing my JS skills for quite a while now. Much as I have loved ActionScript-based development (and it has loved me), the fact of the matter is, the time has come (actually it came at least two years ago); get urgent about JavaScript technologies, both client and server-side, or get run over by industry urgency.

If you don't, you assume a lot of risk:

• Users will complain. They want flexible, adaptive apps that update with new features frequently. 
• Your talent pool will suffer: UI engineers and developers know that confining yourself to ActionScript based technologies is short sighted in terms of career.

Believe me, I have nothing against Flash based technologies. But the wheel has turned; if you're not already actively moving this way...well...not sure how to finish that.

To that end, you have to pick your guns. There's SO much JS out there. I have chosen, as my core study (no surprises here):

• AngularJS
• JQuery
• Node
• The related HTML5 capabilities (local storage, canvas, Server Sent, etc.). 

As far as a packaging technology, I'm looking at Browserify and RequireJS. People are pretty adamant about one or the other, I'm trying to sort it out. (And of course, I keep up on my fundamental Java, I study Clojure when I can, and so on, but that's another discussion. The notion of programming directly to an AST is fascinating to me; I think there's a lot of potential synergy between Clojure and UI). 

I have found (and continue to find as they evolve) these technologies can take care of just about everything, and are relatively stable and well supported compared to the rest of the pack. I get that there's a LOT more and people can be very religious. But I don't think anybody would debate that this is a perfectly acceptable front end stack (and even back end with Node, which I'm increasingly amazed with).

Anyway, I had a conversation with a dev friend, who lamented, "Angular seems great, I want to learn it. But there's SO many modules, so many ways to bootstrap, so many directives...all I want is a simple one pager that shows me how to do the most commonly used, fundamental things."

So I looked around, matched it with what I have found as the most common and basic things I use, and built that simple one pager.

It shows, very simply and without any CSS or other errata that gets in the way of the quanta, which in Angular terms is Controllers, Directives, Filters:

• This is how you tie a Controller to an area of HTML markup. 
• This is how you inject data from that Controller into that markup area. 
• This is how you use directives to control that injection.
• This is how you use filters to further control the injected data. 

Sure, there's way more to learn, and this is by no means how you should plan on writing your apps. But it got my colleague started, so I figured maybe it's a useful cheater.

To use:

You need to have a local or remote web server that you can create a directory on, and put three files in.

If you don't already have a pretty firm grasp of JS and its peculiarities, and don't already have or know how to set up a basic web server (you can use Node, Apache, IIS, Tomcat, whatever), then you have more groundwork to do and really don't belong here yet. 

Those files are:

• The downloaded one (views-directives.html)
• Two "fragment files" (you will need to create these):
• fragment1.html (should contain This is fragment ONE).
• fragment2.html (should contain This is fragment TWO). 

Those fragment files should contain NOTHING else. No html/head/body tags. Just the ... tag (they are fragments, not full HTML files).

Then access this way and it should just work:

http://myHost/myDirectory/views-directives.html

Again, there's no formatting, no nothing. It's VERY bare bones. View the source, read the comments, experiment with the individual pieces to get a feel for it.

Here's the file link:

https://drive.google.com/file/d/0B5V0acodILWkQUJPbFA4UGI4azQ/view?usp=sharing

As always, thanks for visiting.

Inversion of Control, and Dependency Injection (IoC + DI)...uhm...what?

I see it all the time: you ask, "do you know what IoC and DI is." You get, "sure, this framework, and that framework, use them, and I've used those frameworks. And DI is something you do every time you create an instance and pass it as an argument. Three common examples are RobotLegs (ActionScript), Angular JS (JavaScript), and Spring (Java)."

"Ok...now without naming a framework, or using an example from one, in fact without referring to technology at all, tell me what IoC and DI are, and why they are generally spoken of in the same sentence."

If it's a phone conversation, I begin to hear the telltale save-me-Google keyboard taps. If it's in person, I see the forehead produce the uncomfortable light sweat. And I'm not talking junior guys and such; I'm talking Master's degrees, PhDs, the whole bit.

So the honest answer almost every time is, "I use frameworks that have these mechanics. But I really have no idea, apart from the usual 'cleaner/easier' stuff, what these mechanisms are or why the framework designers decided to use them."

It's to be expected. I've never--literally not once--found a simple explanation of these concepts that is understandable apart from a specific language or technology, or even apart from technology completely. I have actually heard IoC and DI referred to as "magic" in an online course on Angular with no further explanation. What is the idea of it?

The following is typical of what I've found, these from WikiPedia:

"In software engineering, inversion of control (IoC) describes a design in which custom-written portions of a computer program receive the flow of control from a generic, reusable library. A software architecture with this design inverts control as compared to traditional procedural programming...Inversion of control is used to increase modularity of the program and make it extensible,^[1] and has applications in object-oriented programming and other programming paradigms."

 "Dependency injection is a software design pattern that implements inversion of control and allows a program design to follow the dependency inversion principle."

That's just not going to do it. The techno babble is confusing, and increased modularity and so forth (cleaner code, more testable, etc.) aren't good enough reasons; people often respond, "I know how to write modular code and test it, I don't need the overhead of some framework for that."

Thing is, they're correct. You don't. So why bother?

I came up with the following a while back. I've delivered it more than once, and it seems to do the trick.

Say I run a service. It's front-ended by a long desk with a number of employees standing behind it. Sort of like the counter at McDonalds, or an old bank teller counter. Behind these employees are all kinds of filing cabinets, with dozens of drawers. Each drawer is labeled with the name of the part it contains.

It's the job of each employee, to hand out a box with the "part du jour" to any customer that walks up to the counter.  

When employees arrive in the morning, they look at a board in the back room that tells them what the part du jour is; some write it down, some use memory, whatever. Each employee then goes to their station at the counter. When a customer walks up to the counter and asks for a part du jour (whatever it might be that day), an employee goes to the filing cabinets, finds a drawer that contains the correct part, takes one out, places it in a box, then returns to the counter and gives the box to the customer.

Potential shortcomings and failures in this system:

• What if the part du jour needs to change during the day? 
• What if one of the drawers in the filing cabinet is poorly labeled? 
• What if the employee simply misread the board, or forgot and guesses?
• What if you need to recall and replace all the parts that were handed out that day? 

And who knows what else.

At this point, people generally start to talk about enhancing the Employee.

• Create a process to notify employees of a change in the part.
• Create a process by which the employee can ensure they got the right part from the drawer.
• Create a process that tests the employee's understanding of what was on the board.
• Create a process such that employees take down the names and addresses of all customers.

Starting to sound like some software projects you may have been involved in?

Unfortunately, none of this will really solve the problem; these "fixes" will in fact aggravate it, because the root cause of the problem is that the employee has too much responsibility, a great deal of which has nothing to do with their main function; customer service. Adding more unrelated responsibility to the employee may get you some short term tactical success, but will fail as a strategy.

To use the parlance of IoC and DI:

The root cause is that the Employee is in Control of Injecting the Dependency into the Box, and shouldn't be.

It translates easily to programming.

• The Employee is a Class, a View, etc; a thing that is supposed to have a well defined responsibility, and that interacts with Customers that need parts from it. 
• A Customer is another class, a function, a user interface components that displays data, etc; some element that needs a Dependency Injected from an Employee. 
• A Dependency is a part the Employee packages and hands out to the Customers that need it. 

So if a given Employee packages and hands out the wrong Dependency, the system will break down at the Customer level somewhere, and you will have to backtrack to find the Employee that gave that Customer the wrong Dependency. Hopefully, this doesn't happen in more than one place or you will have a lot of debugging and fixing to do.

And then, what if one day, you need to issue a recall and replace a given part from every Customer that uses it? Break out the Red Bull.

So on goes the anecdote:

But what if you did this: 

Create a small team, call them "Packing," which is responsible for packing the boxes. They make pre-packaged boxes available to the Customer Service Employees, who in turn give them to the Customers. 

This small team of Packing Employees has a completely separate and specific process for ensuring they put the correct part du jour (Dependency) in the boxes. The Customer Service Employee no longer has the overhead of selection and packing, and can focus entirely on Customer Service. 

In other words, the packing Control has been Inverted away from the Customer Service Employee to a specialized Packing Team. 

With this "framework" methodology of specialized elements interacting to perform a complex task, how many packing errors can a Customer Service employee make? The answer, is...zero. The only mistake they can make is to somehow never give the package to the Customer, which would be a clear failing of the Customer Service process, not Packing.

I get these kind of follow on questions, all good ones:

But...what about the Packing Team? Can't they make a mistake?

Sure they can. But again, they have a specialized process. Their ONLY job is to ensure they are putting the right part in the boxes. It involves inspection, validation, etc. Everything you need done to ensure proper packaging, but shouldn't be making your Customer Service Employees responsible for.

How does this make the process more airtight?

All employee jobs are much more clearly defined. If a Customer didn't a get a box, you talk to Customer Service. If a Customer got the wrong Dependency, you talk to Packing.

But doesn't this mean more overhead? You have to hire more employees, create more processes?

In a way, this is true. But, if you don't break apart these responsibilities, you'll eventually place so much responsibility on Customer Service that they won't be able to keep up with the demand for Dependencies; the system will cease to scale. By breaking the roles apart and implementing more specialized processes as a framework, you make problems easier to find, and can tweak one process without involving the other.

So there you have it: IoC and DI working together to create more stable, easier to fix and maintain, systems. Read the Wikapedia definitions again; hopefully they make more sense.

Of course there's a lot more to it, but this generally gets the conversation going in the right direction, and I usually see the listener start to discuss opportunities to use IoC and DI together.

As always, thanks for visiting.