AIS developed a prototype that highlights the features and capabilities of open standards for geospatial processing and real-time data sharing through web applications. If you haven’t already, please click here to read part one.
After getting the VIIRS data into our application using GeoServer, our next objective was to enhance the prototype to demonstrate some of the exciting things AIS is able to do through the use of various web technologies. Our goal was to provide a highly collaborative environment where clients on a variety of devices could all interact in real time with map data.
Our client, The National Football Players Association (NFLPA), approached us regarding the development and implementation of a new player management system called PA.NET. AIS accomplished this project by managing the engagement in two phases: An envisioning phase to gather and define requirements and develop a roadmap for the reengineering initiative, followed by an implementation phase to support the development of a PC, tablet and mobile phone application design to ensure accessibility across multiple platforms and increase mobility and efficiency.
In an earlier blog post, I discussed JavaScript functions at length. If you found yourself on Team Scar before, hopefully that post made you start thinking about switching sides; conversely, if you already liked JS, I hope I didn’t ruin it for you! I mentioned that I would cover JavaScript scope in my next post, so let’s get on with it!
If you learned C/C++, then went on another C-style language (i.e. Java or C#), then you are very much like me. Scope in those languages is created by { }. In JS, relying on { } to define your scope is just pointless. Functions create scope. Only functions can create scope and anything outside of a function exists as a part of the global object. Most of the frustration towards JS is probably due to developers misunderstanding it. Sure, the language does have some design flaws, but what language doesn’t? Read More…
Are you a developer who adamantly hates JavaScript and would give up your firstborn before taking on a project that involves said language? If so, you are not alone. JavaScript seems to be one of those languages that polarizes us into two groups:
TEAM SIMBA
Members of this group believe JS is the rightful king of the web (and possibly server). They believe JS is easy and fun to develop with and mature enough to handle anything you throw at it. They praise the language for its impressive developer community and rich ecosystem of libraries.
TEAM SCAR
Members of this group believe JS is a twisted and deceitful language. They are obstinate that JS is a broken language flawed from its conception and mired by designers and the 90s. They see the language and its associated tooling as too “immature” for any real work. Of course, all JS libraries are just the hyena minions sent upon the web (and now server) to ravage and uglify the beautiful landscape that computer scientists have diligently built over the past six decades.
I believe both groups have valid points. JS can be a bit idiosyncratic at times. I have been burned a few times by many of the questionable “features” of the language. For example, double-equals is not equivalent to == present in many C-style languages:
if ("" == 0) //this statement is true...
console.log("Seriously?!")
The above code snippet is known to make minds explode!
If you are like me, you probably learned C or some language based/inspired by it. The reason behind the behavior above is that == actually is an equality operand that performs type-coercion first. But there are also some very neat things going on in JS, and perhaps the best attribute is function-passing. There is great power in the ability to pass functions as arguments — just ask any Scala programmer! While functions are fundamental to JS, they are a topic that confuses a lot of developers, so let’s get started. Read More…
Let me state at the outset, I have no intention to compare “JavaScript with HTML” and “C# with XAML” styles of building Windows Store Apps. This is a choice you have to make based on your skillset, reuse considerations (i.e. do you plan the target the app for Windows 8 and Windows Phone 8 OS), whether the functionality you are targeting for the app is already available as a web app or not, etc.
For last several years I have focused on the web technologies, starting with server-side technologies but lately client-side single-page style apps. So the h5c3js model is more suitable based my skillset. (Additionally, my knowledge of XAML is limited to WF serialization format.)
This model, which allows HTML-based native Windows 8 apps, is innovative in my opinion and I applaud the folks responsible for the language projection in Windows RT.
I’m not going to try and convince you that mobile development is important – I hope you already recognize that it is! If you need further convincing, head on over to Allison Christman’s article – she gives you all the reasons you’ll need. However, while she mainly discussed mobile websites, I’d like to give an overview on mobile applications and their development methodologies. Should you build for the platform or the browser? Or both? What is the difference between a mobile website and a mobile application? What is a hybrid application? Knowing the strengths and weaknesses of each approach is vital when making the decision on how to best reach and serve your end-users. Read More…
Here at AIS, we’ve found Windows Azure Blob Storage to be an inexpensive, fast hosting solution for non-text or server-side loaded resources. But what if we want to use client-side JavaScript to load HTML fragments or JSON data directly from blobs? Under normal circumstances this is prevented by JavaScript’s Same Origin Policy; that is, you can’t load HTML fragments or JSON from another domain, subdomain, port or protocol.
One commonly used solution to this restriction is JSONP, but this is not available with Azure Blob Storage. Another modern option is Cross-Origin Resource Sharing (CORS), but it is also unavailable on Azure Blob Storage and not supported in some legacy browsers.
We could consider a server-side solution, such as employing an Azure Web Role to read text-based content from blob storage and serve it up from the original server. But this approach can be both wasteful and performance inhibiting.
When it comes to the Web Forms vs. MVC debate, the question isn’t “Which is Better?”…but “How to Switch?”
I have been studying and trying to transition to Model-View-Controller (MVC) for about six months and I have come across some fundamental thinking that must be changed and new things that must be learned in order to make the switch. I worked with Web Forms extensively in my previous position, and since joining AIS have made a commitment to myself to embrace the switch. I am still learning, but this is what I have found so far (your results may vary).
