tag:blogger.com,1999:blog-53878952480653471582024-03-05T01:58:28.057-08:00Software Design MattersThink before do.Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-5387895248065347158.post-40005528083072366612015-09-02T13:07:00.000-07:002015-10-05T09:57:39.883-07:00Up-front software design can make development more agile<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIS7GvUFjZ0TfWl-_Pz2cej21_iYl4IYylAMRmSezzJjbsmKY4IycGtPpbh3K6z9V9zFXdg66-mHQaB6SNKRglHgROvMv1jYYx2fUQ91rlqW71-QbfdhsISgPVk6uHCtmmAyDmrOjOEvY/s1600/bigstock--raster-image-of-vector-yin-a-16181438.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIS7GvUFjZ0TfWl-_Pz2cej21_iYl4IYylAMRmSezzJjbsmKY4IycGtPpbh3K6z9V9zFXdg66-mHQaB6SNKRglHgROvMv1jYYx2fUQ91rlqW71-QbfdhsISgPVk6uHCtmmAyDmrOjOEvY/s200/bigstock--raster-image-of-vector-yin-a-16181438.jpg" width="200" /></a>Although the<a href="http://www.agilemanifesto.org/principles.html"> agile manifesto</a> promotes the idea that “Continuous attention to technical excellence and good design enhances agility”, there’s been a movement in agile project management away from up-front software design. While it's generally accepted that requirements will change during most projects, and therefore <a href="https://en.wikipedia.org/wiki/Big_Design_Up_Front">big design up front </a>no longer makes sense, the other extreme is not desirable either. No up-front design can result in a <a href="https://en.wikipedia.org/wiki/Software_entropy">mess</a> that <i>reduces</i> agility, a mess that is <a href="https://en.wikipedia.org/wiki/Technical_debt">increasingly expensive</a> to correct as the project progresses and often hidden from the business. It can happen even when <a href="https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small#Programming_in_the_small">developing within frameworks</a> like Ruby on Rails, ASP.NET, J2EE, and Django that provide some design ‘out of the box’. Even when using <a href="https://en.wikipedia.org/wiki/Code_refactoring">code refactoring</a> tools. Designing up-front for change, on the other hand, can be lean and help maintain agility, even as the code grows. <br />
<br />
Designing for change includes identifying units of functionality, considering which are more likely to change based on competitive environment or end user needs, then isolating them into logical parts in such a way that those less likely to change are not dependent on those that are as much as possible. For those who want to get a glimpse of how this looks under the hood, this presentation illustrates some common examples of software designs that improve agility. <br />
<br />
<script async="" class="speakerdeck-embed" data-id="2c01b74aada143718f2512230ac61b43" data-ratio="1.6" data-slide="11" src="//speakerdeck.com/assets/embed.js"></script>
<br />
<a href="https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small#Programming_in_the_small">Frameworks</a> that provide design structure take care of some of this, but not all. Applying design practices like identifying, naming, and capturing the properties (as much as possible) of the units of data in an application up-front, for example, can return dividends from day one that further increase with time. Not doing so can easily result in data units that are ambiguously named, vary by developer, and even overlap with one another. It's not hard to imagine that after even a few thousand lines of code the time cost to change these units goes up and from there just keeps rising. After all, even with software tools that make changing databases easy, there's still all the surrounding code that has to be dealt with.<br />
<br />
Some up-front design really can go a long way to improve agility and there are sensible, lean ways to go about it. Since doing so isn't popular at the moment, however, it may be something you want to make sure is happening on your projects.<br />
<br />
What's your experience with adaptable designs and maintaining agility as your software grows? What's your team doing to avoid a mess? Please share
your thoughts and experiences in the comments below. Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0tag:blogger.com,1999:blog-5387895248065347158.post-84499352188211404892015-01-08T15:15:00.000-08:002015-06-08T22:52:19.235-07:00The mobile dream: write once, run everywhere<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglhcB7GqMBkzShxO92vwl5NAKgxwmjjVJtGnFDFzSbbnJVvji8InAV7229WzXzq2VCmMhGoEmpezDtGyFjpFXLAQbWLIEQHnBdprJEu_tfnzpz_ElRKntYOp05nDY5RMp0Yqvoipd6hIg/s1600/CMFIntroPage4.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="148" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglhcB7GqMBkzShxO92vwl5NAKgxwmjjVJtGnFDFzSbbnJVvji8InAV7229WzXzq2VCmMhGoEmpezDtGyFjpFXLAQbWLIEQHnBdprJEu_tfnzpz_ElRKntYOp05nDY5RMp0Yqvoipd6hIg/s320/CMFIntroPage4.png" width="320" /></a>It's come up before. Someone has a cross-platform mobile app written in HTML5 (HTML version 5 with CSS and JavaScript) and they're thinking of porting it to native to improve performance. But native can be very costly and HTML is a ubiquitous, cross-platform technology already baked into
most (all?) smart devices (not to mention the web itself). HTML is also
arguably one of the more productive user interface development
technologies around, having had time to evolve since the inception of the web. And yet those pesky performance issues with
HTML5 crop up on mobile devices. Hesitant button toggles. Flickering transitions.
Noticeable screen redraws. Neither costly development or poor performance are very satisfying choices.<br />
<br />
There are a variety of alternatives, each with benefits and drawbacks. In this post I'll attempt to survey the major options and end up coming virtually full circle to a practical approach I recommend considering: keep as much in HTML5 as possible and then optimize by pulling just the problems into native. The trick here is pulling <i>exactly </i>the problems into native: unless your problem areas exactly match what commercial native shells happen to provide (i.e. Phonegap, Trigger.io, etc.) it's probably easiest to provide the native shell yourself through some native coding. <br />
<br />
But first, what are the major alternatives?<br />
<br />
<h3>
HTML5 packaged in native shell </h3>
<br />
<h4>
<a href="http://phonegap.com/" target="_blank">Phonegap </a>/ Cordova</h4>
<h4>
</h4>
With this technology, an app is <a href="http://www.smashingmagazine.com/2014/02/11/four-ways-to-build-a-mobile-app-part3-phonegap/" target="_blank">primarily written in HTML5 then bundled into a wide variety of native packages</a>.
Hardware services are provided through plugins and offered to the
bundled HTML5 through a bridging API. App developers can add new plugins,
which are developed separately in native code for each platform. Basic Phonegap is free
and supports all major mobile platforms. <br />
<br />
Phonegap apps are known as having performance challenges, some from the hosted HTML5 and others from the communication between HTML5 and native code. While it should be possible
for Phonegap to improve HTML5 performance by <a href="http://devgirl.org/2014/11/10/boost-your-ios-8-mobile-app-performance-with-wkwebview/" target="_blank">using Apple's WKWebView in iOS 8,</a> and it<a href="http://trigger.io/cross-platform-application-development-blog/2012/02/24/why-trigger-io-doesnt-use-phonegap-5x-faster-native-bridge/" target="_blank"> has been possible for Phonegap to improve its bridging communication for quite some time</a>, it's mandate to serve the 'widest possible audience' means these potential improvements are still not available. It's tough trying to be
everything to everyone without becoming barely average to everybody.<br />
<br />
<h4>
<a href="http://trigger.io/">Trigger.io</a></h4>
<h4>
</h4>
Similar to Phonegap,
much of a trigger.io app is written in HTML5 and bundled into native
deployment packages, with native device capabilities like the camera
extended to HTML5 though a bridge. <a href="https://trigger.io/how-it-works/">Trigger.io also, however, exposes native UI components to the bundled HTML5 code through their bridge</a> enabling hybrid user interfaces. Trigger.io claims their native to HTML bridge technology is <a href="http://trigger.io/cross-platform-application-development-blog/2012/02/24/why-trigger-io-doesnt-use-phonegap-5x-faster-native-bridge/">up to 5x faster than Phonegap on Android</a>. Trigger.io also supports writing custom native plugins, similar to Phonegap, which it calls <a href="https://trigger.io/docs/current/api/native_modules/index.html">modules</a>.
Trigger.io is offered through a monthly subscription and appears to
only support iOS and Android. Trigger.io clearly aims to fill in where
Phonegap falls short.<br />
<br />
As with Phonegap, its
value probably comes down to whether your performance issues happen to match what it can provide natively -- and how uncomfortable you are taking on a little
native development. <br />
<br />
<h4>
<a href="http://rhomobile.com/" target="_blank">RhoMobile Suite</a></h4>
<h4>
</h4>
RhoMobile apps are written in a combination of HTML5 and Ruby. Most views are written in HTML5 and rendered with the embedded browser component as with Phonegap, with the <a href="http://osdir.com/ml/rhomobile/2010-07/msg00514.html" target="_blank">addition of controllers written in Ruby</a> that can provide native functionality including native tab
bars, navigation bars, map views, date pickers, and others. On BlackBerry, RhoMobile apps are converted to and run as Java
bytecode. On iOS, Android, and Windows Phone, apps are compiled down to and run as Ruby 1.9 bytecode. RhoMobile has a free option on up to monthly per developer subscription price.<br />
<h3>
</h3>
<h3>
Interpreted</h3>
<h3>
</h3>
<h4>
<a href="http://www.appcelerator.com/titanium/" target="_blank">Appaccelerator Titanium</a></h4>
<h4>
</h4>
Unlike those described thus far, Titanium apps do not use an internal browser component. Titanium instead uses JavaScript, run in a JavaScript interpreter, to control native user interface elements through platform-independent JavaScript APIs. Since it can be a little hard to figure out how this works, <a href="http://stackoverflow.com/questions/4217551/what-happens-to-javascript-code-after-app-is-compiled-using-titanium-mobile/4798547#4798547" target="_blank">here </a>and <a href="http://stackoverflow.com/questions/2444001/how-does-appcelerator-titanium-mobile-work/2471774#2471774" target="_blank">here</a> are two articles I found particularly informative. Titanium is open source and can build apps for iOS, Android, Blackberry, Tizen, and Windows Phone. <br />
<br />
As with any fairly large body of technology (probably all included here!), issues have been noted with Titanium. It may be most suitable for prototyping as <a href="http://enricoangelini.com/2012/5-pros-and-cons-of-appcelerators-titanium/" target="_blank">performance issues</a>, difficulties in debugging, and <a href="http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/" target="_blank">memory issues</a> have been noted. <br />
<br />
<h4>
<a href="http://coronalabs.com/" target="_blank">Corona</a></h4>
<h4>
</h4>
Corona seems to be focused on the development of<a href="http://www.techrepublic.com/blog/software-engineer/cross-platform-vs-native-development-corona-sdk/" target="_blank"> mobile games</a>, although it can also build other types of apps. Apps in Corona are written in LUA and are probably<a href="http://tedpatrick.com/2011/01/22/corona-a-short-stack/" target="_blank"> interpreted by a proprietary interpreter written in C</a>. Corona can produce apps for iOS, Android, Kindle, and Windows Phone and is priced on a per-developer, subscription basis.<br />
<br />
<h3>
Compiled to assembly </h3>
<h3>
</h3>
<h4>
<a href="http://xamarin.com/" target="_blank">Xamarin</a></h4>
<h4>
</h4>
Xamarin came out of work done on Mono, an open source .NET implementation. Xamarin apps are written in C# and can be deployed to iOS, Android, and Windows. For iOS,<a href="http://developer.xamarin.com/guides/cross-platform/getting_started/introduction_to_mobile_development/#How_Does_Xamarin_Work" target="_blank"> Xamarin produces</a> a completely native app by compiling C# to ARM processor assembly. For Android, C# is compiled to .NET IL then packaged with the monoVM and JIT. Xamarin can produce apps for iOS, Android, and Windows Phone. <br />
<br />
Not to pick on Xamarin but since I've heard it promoted heavily as a way to write once run everywhere I suggest reading <a href="http://www.whitneyland.com/2013/05/why-i-dont-recommend-xamarin-for-mobile-development.html" target="_blank">this article</a> if you're considering Xamarin for that reason.<br />
<br />
<h4>
<a href="https://www.embarcadero.com/" target="_blank">Embarcadero Firemonkey</a></h4>
<h4>
</h4>
Firemonkey apps are written in Delphi or C++ and are <a href="https://www.embarcadero.com/products/application-development/multi-device-true-native" target="_blank">compiled directly to processor assembly</a> for both the iOS and Android mobile platforms, completely replacing native compilation. Firemonkey tools are priced in the $1000s per user range. <br />
<br />
<h3>
HTML5 (..and can be packaged in Cordova)</h3>
<h3>
</h3>
Another approach to improving HTML5 performance is to <a href="http://www.html5rocks.com/en/tutorials/speed/html5/" target="_blank">optimize HTML5 itself</a>. This approach is, of course, limited in effectiveness by the performance of the browser running the HTML5.<br />
<br />
HTML5 running in Safari or Chrome already benefits from improvements to both, and those benefits have been recently extended to the embedded browsers native <a href="http://developer.telerik.com/featured/why-ios-8s-wkwebview-is-a-big-deal-for-hybrid-development/" target="_blank">iOS </a>and <a href="https://developer.android.com/guide/webapps/migrating.html" target="_blank">Android </a>code can host. HTML5 may not be able to fully compete performance-wise with native code yet, but clearly vendors are putting investment in this area and arguably the gap is closing. <br />
<br />
A few HTML5 libraries of note, each of which can be natively packaged in Cordova, include:<br />
<br />
<h4>
<a href="http://ionicframework.com/" target="_blank">Ionic</a></h4>
<h4>
</h4>
This mobile JavaScript library is focused on performance and features 'no jQuery'. Ionic JavaScript is structured <a href="http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller">MVC </a>using <a href="https://angularjs.org/" target="_blank">AngularJS</a>.<br />
<br />
<h4>
<a href="http://www.sencha.com/products/touch/" target="_blank">Sencha Touch</a></h4>
<h4>
</h4>
Sencha Touch is known for its good native look and feel and is also clearly <a href="http://www.sencha.com/blog/5-myths-about-mobile-web-performance/" target="_blank">sensitive about performance</a>. It's also known to be a bit of a learning curve. It The challenge with Sencha, in my opinion, is that its focus on <i>native </i>look and feel suggests it may be a poor fit when using HTML5 as the cross-platform portion of an app.<br />
<br />
<h4>
<a href="http://jquerymobile.com/" target="_blank">jQuery Mobile</a></h4>
<h4>
</h4>
This library produces a native-<i>independent </i>look and feel, what you're usually looking for for the cross-platform potion of apps. It's fairly easy to pick up and work with in my opinion, but of course jQuery's focus on DOM manipulation doesn't result in well-structured code on its own. I found it performed adequately even in older Android browsers and <a href="http://modernweb.com/2014/03/10/is-jquery-too-big-for-mobile/" target="_blank">agree </a>performance issues others have complained about may be from some other cause.<br />
<br />
<h4>
<a href="http://www.telerik.com/appbuilder" target="_blank">Telerik Mobile</a></h4>
<h4>
</h4>
Frankly, I found it a real challenge to figure out what this thing is or does (can you figure out what all <a href="http://www.telerik.com/" target="_blank">this marketing bling actually means</a>?), but from what I can tell they provide the following mobile development technologies (in addition to other non-mobile ones):<br />
<ul>
<li>A <a href="http://www.telerik.com/kendo-ui" target="_blank">JavaScript library (with tools)</a> to help produce HTML5 apps that adapt to each native look and feel </li>
<li>Tools to <a href="http://www.telerik.com/appbuilder" target="_blank">package</a>, manage, test, and analyze HTML5 apps packaged in a native Phonegap/Cordova shell.</li>
</ul>
<h3>
</h3>
<h3>
Back to the beginning</h3>
<h3>
</h3>
Whew. A lot of different technologies to make the same code run on different devices, and there's even more than I mentioned. But do any of the alternatives really save on cost (time, money, headache) over what the mobile platforms themselves already provide?<br />
<br />
I believe native will always have the most complete set of features, best debugging, best support, best compatibility -- you name it. It will be where you have to go in a pinch. And even the fiercest mobile competitors are taking HTML5 seriously so it's hard for me to recommend ignoring it.<br />
<br />
In contrast, none of the alternatives have the same mind share, not even close, which adds to their long-term costs. How easy will it be to get bugs fixed when you run
into them? How hard will it be to work around something when you need it done a little differently? How long will it take to
learn? Frankly, how long will it continue to be a viable and supported product? A lot changes in a few years.<br />
<br />
So, if you have a cross-platform mobile app written in
HTML5 and need to improve performance, consider pulling the performance issues into native before you pull the plug and either go all native or with a completely different alternative. If the existing technologies that package HTML in a native shell don't let you move performance issues to native exactly where you need it, consider rolling your own. Doing so isn't hard if you're handy with a little native development -- certainly not harder than tackling a whole new development platform -- and it enables you to use both native and HTML's strengths when and where you need them. <br />
<br />
Tell me what you think. It's a big topic and of course there aren't really any simple answers.Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0tag:blogger.com,1999:blog-5387895248065347158.post-33512568006329843522014-12-18T15:59:00.000-08:002015-03-20T14:00:02.460-07:00A bottle of DB relieverI don’t know about you, but trying to decide what technologies to use is beginning to feel like trying to choose a pain reliever: countless choices and a ton of small print. But when you think about it, it’s actually worse. Unlike pain reliever brands that tend to stick around year after year, many technologies don’t. <br />
<br />
So in a new world liberated from the tyranny of expensive database technologies but buried in choices that will live or die depending on where the tech fashion winds blow, which do you choose?<br />
<br />
I found <a href="http://db-engines.com/en/" target="_blank">this site</a> particularly helpful for getting the big picture because it not only provides a survey of what’s out there but categorizes and ranks them based on popularity. This way I can survey the different categories of database engines, learn more about the players, and see how they’re popularity is trending.<br />
<br />
Then I only have to dig into the small print on a few bottles before heading over to toothpaste...Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0tag:blogger.com,1999:blog-5387895248065347158.post-26906592453293671342014-10-17T14:01:00.000-07:002014-11-04T11:18:55.096-08:00Posting files with AngularJS<br />
While AngularJS's built-in <b><span style="font-family: "Courier New",Courier,monospace;">$http</span></b> service posts data as JSON by default, what do you do if you need to include an image or other binary data file in the post?<br />
<br />
Seems pretty straightforward. Just bind HTML <span style="font-family: "Courier New",Courier,monospace;"><b><input type="file"></b> </span>to a controller variable via <b><span style="font-family: "Courier New",Courier,monospace;">ng-model</span></b> and <b><span style="font-family: "Courier New",Courier,monospace;">$http.post()</span></b> a <b><span style="font-family: "Courier New",Courier,monospace;">FormData</span></b> object containing the file object as data with<span style="font-family: inherit;"> <b><span style="font-family: "Courier New",Courier,monospace;">Content-Type</span></b> set to <b><span style="font-family: "Courier New",Courier,monospace;">multipart/form-data</span></b><span style="font-family: inherit;">. R</span>ig</span>ht?<br />
<br />
Not so fast. It turns out that<b> </b><br />
<ul>
<li><b> </b><span style="font-family: "Courier New",Courier,monospace;"><b><input type="file"></b> </span>doesn't work with <b><span style="font-family: "Courier New",Courier,monospace;">ng-model</span></b>, and </li>
<li>Setting <b><span style="font-family: "Courier New",Courier,monospace;">Content-Type</span></b> to<span style="font-family: "Courier New",Courier,monospace;"> <b>multipart/form-data</b></span> resulted in rejected posts (a bug?). </li>
</ul>
<br />
Thankfully Angular is thoughtfully extensible. The first issue can be resolved with a custom Angular <b><span style="font-family: "Courier New",Courier,monospace;">directive </span></b>that tells <b><span style="font-family: "Courier New",Courier,monospace;">$compile</span></b> to hook <span style="font-family: "Courier New",Courier,monospace;"><b><input type="file"></b> </span>change events and set a controller scope variable with the selected file object when fired as so:<br />
<br />
<pre style="background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"><b> .directive('<span style="color: blue;"><span style="background-color: white;">inputfileModel</span></span>', ['$parse', function ($parse) {
return {
link: function(scope, element, attrs) {
var model = $parse(attrs.inputfileModel);
var modelAssigner = model.assign;
<span style="color: red;"> element.bind('change', function(){
scope.$apply(function(){
modelAssigner(scope, element[0].files[0]);
});
});</span>
}
};
}]); </b>
</code></pre>
<br />
This directive is then set on the element as a custom element attribute:<br />
<br />
<pre style="background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"> <b> <input type="file" <span style="color: blue;"><span style="background-color: white;">inputfile-model</span></span>="fileVar"> </b>
</code></pre>
<br />
<br />
The second issue is a little trickier to work around. After doing some digging, it turns out
that setting <b><span style="font-family: "Courier New",Courier,monospace;">Content-Type</span></b> to <span style="font-family: "Courier New",Courier,monospace;"><b>undefined</b> </span>results in browsers both setting <b><span style="font-family: "Courier New",Courier,monospace;">Content-Type</span></b> to <b><span style="font-family: "Courier New",Courier,monospace;">multipart/form-data</span></b> and filling in the correct boundaries. O-Kay, not sure why that is, but hey, it works. Note that $http.post()'s default behavior of transforming data to JSON also needs to be turned off, which can be done by setting it to Angular <a href="https://docs.angularjs.org/api/ng/function/angular.identity" target="_blank"> identity function</a> if you're into functional style programming.<br />
<br />
<pre style="background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"><b> .factory('Messages', ['$http', function ($http) {
return {
put: function(url, file, dataObj, success, error) {
var fd = new <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/Using_FormData_Objects" target="_blank">FormData</a>();
fd.append('json', JSON.stringify(dataObj));
fd.append('file', file);
<a href="https://docs.angularjs.org/api/ng/service/$http#post" target="_blank">$http.post</a>(url, fd, {
<span style="color: blue;">transformRequest: angular.identity</span>,
headers: {<span style="color: blue;">'Content-Type': undefined</span>}
})
.success(success)
.error(error);
}
}
}]); </b>
</code></pre>
<br />
<code><b></b></code><br />
A few problems initially, but it wasn't too hard to modify and using frameworks like Angular to add some structure to JavaScript in all its expressive glory can only help ease the pain of the poor dude down the road who will have to maintain it. <br />
<ol><ol><ul>
</ul>
</ol>
</ol>
<ol><ol><ul>
</ul>
<ol>
</ol>
</ol>
</ol>
Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0tag:blogger.com,1999:blog-5387895248065347158.post-91801594027043875962013-06-01T14:41:00.000-07:002015-06-15T12:25:12.574-07:00Get the Gist: UMLSo you have a picture in your head. You can see it. From a variety of angles. What it looks like laying flat, how it stands, how it will work when it becomes real.<br />
<br />
Of course, things we build start out as pictures in our minds and in many cases just sketching out some lines and words is enough to work out the dimensions, the layout, how it will look. Enough to show someone else what it will look like.<br />
<br />
Software can get pretty complex, though. Will the developer across the world understand what your squiggle means? Will the guy who has to maintain the software three years from now? Luckily, engineers and others have studied how humans model things and the techniques they developed can be useful for both thinking through ideas thoroughly and communicating them in an unambiguous way to others. Universal Modelling Language is such a technique, a standard way to model and communicate software ideas.<br />
<br />
UML defines standard ways of diagramming, which is probably its most used -- and useful -- contribution. The problem is there seems to be a pretty wide gulf between a simple napkin sketch and UML and it's 13 (!) types of diagrams (and thick instructional books).<br />
<br />
It doesn't have to be that way, though. In my opinion the most useful aspects of UML boil down to some fairly simple bare essentials readily gleaned from examples which I attempt to provide in the following presentation.<br />
<br />
It's true that refactoring is all the rage with the programming fashionistas. But really, is it ever advantageous to not take a little time to think things through? With a few basics UML can be a pretty useful napkin. <br />
<br />
<iframe allowfullscreen="" frameborder="0" height="355" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/41477790" style="border-width: 1px; border: 1px solid #CCC; margin-bottom: 5px; max-width: 100%;" width="425"> </iframe> <br />
<div style="margin-bottom: 5px;">
<b> <a href="https://www.slideshare.net/russellgmorley/get-the-gist-universal-modelling-language-uml" target="_blank" title="Get the Gist: Universal Modelling Language (UML)">Get the Gist: Universal Modelling Language (UML)</a> </b> from <b><a href="https://www.slideshare.net/russellgmorley" target="_blank">russellgmorley</a></b> </div>
<br />Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0tag:blogger.com,1999:blog-5387895248065347158.post-52167459384357287002013-03-13T15:04:00.000-07:002015-01-03T09:26:02.312-08:00Communication reliability<div style="font-family: Arial,Helvetica,sans-serif;">
<span style="font-size: small;">One
of the most important things to consider when designing communication
between two systems in an enterprise is reliability: Does the sender
need to know if messages were delivered to the receiver? If an error
occurs on the receiver, does the sender need to know? Does the sender
need to know what type of error occurred? Do messages need to be
received in the order they were sent? What about receivers that may go
offline or networks that go down? Does communication need to participate
in a transaction so state consistency is maintained across multiple
systems?</span></div>
<div style="font-family: Arial,Helvetica,sans-serif;">
<span style="font-size: small;"><br /></span></div>
<div style="font-family: Arial,Helvetica,sans-serif;">
<span style="font-size: small;">Before
designing interfaces and selecting network protocols, it's necessary to
understand the reliability requirements of the communication and how
requirements align with the capabilities of protocol standards and
industry techniques. Because the matrix of communications protocol
capability and techniques as related to reliability is rather complex,
it's useful to categorize communication reliability requirements based
the following: </span></div>
<ol style="font-family: Arial,Helvetica,sans-serif;">
<li><span style="font-size: small;"><b>Unordered:</b> Unordered is useful for providing
information to one or more interested receivers quickly. Communication
is one way and does not block. Receivers cannot return information back
to the sender and senders don't know if communication with receivers was
successful.</span></li>
<li><span style="font-size: small;"><b>Receive-reply: </b>For communication to a single
receiver, Receive-reply requires a sender wait for a reply or timeout.
Both information and errors can be returned in the reply and senders
know if communication was successful. </span></li>
<li><span style="font-size: small;"><b>Ordered:</b> Provides ordered communication with
one or more receivers. Information cannot be returned from receivers to
senders but errors can. When configured to return errors, Ordered
communication blocks but otherwise can be configured to be non-blocking.</span></li>
<li><span style="font-size: small;"><b>Guaranteed</b>: A form of Ordered communication,
Guaranteed cannot return information or errors but guarantees delivery
even if the receiver isn't running when sent. </span></li>
<li><span style="font-size: small;"><b>Transactional:</b> Either configured as
Receive-reply or Ordered, Transactional can return information to the
sender if configured as Receive-reply, can always return errors, and can
further participate in a transaction as a durable resource.</span></li>
</ol>
<span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;">In
communication design, reliability requirements informs everything from
the design of the interface operations to protocol selection and is a
crucial part of creating a robust enterprise system. Capturing
reliability requirements in the form of a few simple categories is a
practical way to express business needs in terms real-world protocols
and industry techniques can address</span></span><span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;">. </span></span><br />
<br />Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0tag:blogger.com,1999:blog-5387895248065347158.post-21922725190373532042012-01-04T19:30:00.000-08:002015-01-03T09:23:57.177-08:00The usefulness of adapters: a pictorial<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicP-6qOo3bVrufaMabrK_v6zMZ2Aaou2CQRotzGP3BdJX68QWk1GvYP9Eph3x4hlaSMIFuHSRMMOUZGWf_WVzD5o8m6RMY3uFq5kWTZF99XwTsPuyZeIu7eGtmbWEurl3fUswva55c0aNM/s1600/Adapters.png" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicP-6qOo3bVrufaMabrK_v6zMZ2Aaou2CQRotzGP3BdJX68QWk1GvYP9Eph3x4hlaSMIFuHSRMMOUZGWf_WVzD5o8m6RMY3uFq5kWTZF99XwTsPuyZeIu7eGtmbWEurl3fUswva55c0aNM/s640/Adapters.png" height="640" width="546" /></a>Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0tag:blogger.com,1999:blog-5387895248065347158.post-89379685308251044762011-02-22T15:04:00.000-08:002014-11-12T15:05:29.973-08:00Get the Gist: C++/CLI (or how to do native and managed code at the same time)<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="355" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/41473821" style="border-width: 1px; border: 1px solid #CCC; margin-bottom: 5px; max-width: 100%;" width="425"> </iframe> <br />
<div style="margin-bottom: 5px;">
<b> <a href="https://www.slideshare.net/russellgmorley/get-thegist-c-cli" target="_blank" title="Get the Gist: C++/CLI">Get the Gist: C++/CLI</a> </b> from <b><a href="https://www.slideshare.net/russellgmorley" target="_blank">russellgmorley</a></b> </div>
<br />Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0tag:blogger.com,1999:blog-5387895248065347158.post-80439905260739435202011-01-13T14:53:00.000-08:002014-11-12T15:02:35.092-08:00C# for C++ ProgrammersC++ isn't known as being the easiest programming language, so if you have it under your belt "getting" C# shouldn't be a problem. Here's a hint: if you know anything about Java think "Microsoft's Java".<br />
<br />
Anyway, here's an overview to get you started:<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="355" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/41473819" style="border-width: 1px; border: 1px solid #CCC; margin-bottom: 5px; max-width: 100%;" width="425"> </iframe> <br />
<div style="margin-bottom: 5px;">
<b> <a href="https://www.slideshare.net/russellgmorley/csharp-for-cpp-programmers" target="_blank" title="C# for C++ Programmers">C# for C++ Programmers</a> </b> from <b><a href="https://www.slideshare.net/russellgmorley" target="_blank">russellgmorley</a></b> </div>
<br />Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0tag:blogger.com,1999:blog-5387895248065347158.post-42297253274873636672010-11-08T15:01:00.000-08:002014-11-12T15:02:21.013-08:00Get the Gist: How .NET works.Here's an overview of how .NET works I put together a few years ago. The .NET framework is continually growing but it still basically works the same under the hood:<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="510" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/41473820" style="border-width: 1px; border: 1px solid #CCC; margin-bottom: 5px; max-width: 100%;" width="477"> </iframe> <br />
<div style="margin-bottom: 5px;">
<b> <a href="https://www.slideshare.net/russellgmorley/get-thegist-dotnet" target="_blank" title="Get the Gist: .NET">Get the Gist: .NET</a> </b> from <b><a href="https://www.slideshare.net/russellgmorley" target="_blank">russellgmorley</a></b> </div>
Russell Morleyhttp://www.blogger.com/profile/13541329888927677921noreply@blogger.com0