16 Mar 2017 @ 11:07 PM 

Well, this was a pain to search for.  First I searched for the meaning of NuGet, which lead me to NuPack.  Hmmm, ok.  So then I looked that up, and found Nubular, which apparently had something to do with ruby packages. Interesting.  It appears, since Perl had SPAN, and ruby had gems, the .Net folks took notice (around mid 2010) and also wanted one for .Net, which is when Nubular was born (around August 2010).  The story has it they named it “Nubular” because it was, well, “tubular dude”. ;) Of course, it had to start with “N” because it was for .Net after all. At the time, the way to install Nubular was to first install Ruby and use Gem to get Nubular.

Around this same time, it appears Microsoft was also working on their own package management system for .NET, which they were calling NPack (starting with ‘N’, for obvious reasons, lol). After hearing about Nubular, they decided to open source NPack with the help of Nubular developers.  The new project was renamed to NuPack, and was among the first times Microsoft worked with the open source community.

Later in 2010 it was ready to be released as an extension to Visual Studio.  Apparently, due to a conflict with other existing software called NuPack, they renamed it to NuGet, and thus, henceforth, has been the name ever since. ;)


Posted By: James
Last Edit: 16 Mar 2017 @ 11:09 PM

EmailPermalinkComments (0)
Categories: Coding, General
 09 Feb 2016 @ 9:05 PM 

You have no idea how much I HATE it when support for a software product or online service tells me something was “designed that way”.  If something isn’t working as expected, or becomes a road block for usage, it should not be easily dismissed.  Why don’t more software companies take more hints to these responses and better fix the issue? I get more the feeling these support correspondences fall along the wayside never to be seen again.  Let me coin a term here: BOPs – Bugs On Purpose (or perhaps BBD – Bugs By Design?) ;)

Posted By: James
Last Edit: 23 May 2017 @ 11:36 PM

EmailPermalinkComments (0)
 26 Aug 2015 @ 7:48 PM 

I was recently curious if the new features of ES6+ for JavaScript will make it the language of choice as time goes, and a side curiosity about the future of Java vs C#. Here are some stats online for the languages, which some may find interesting:

1 JavaScript (now king!)
2 Java (falling down very slowly, except Android development is keeping it up)
4 Python
5 C# (and rising)
5 C++ (this is still high due to games and high-speed requirements)
5 Ruby
9 C
10 Objective-C
11 Perl
11 Shell
13 R
14 Scala
15 Haskell
16 Matlab
17 Go
17 Visual Basic
19 Clojure
19 Groovy

Source: https://goo.gl/GR8Ele

Other interesting stats:

From Monster.ca:

- Java: 145 (and falling), full-time, $100k+
- .Net: 71 (and rising), full-time, $100k+
- Web developers: 90, full-time, $100k+ (implies JavaScript in most cases, which cannot stand alone like the others)

Here are some stats from over 2000 employers: http://goo.gl/lSBgAw
Summary: C# % change is skyrocketing. Java has lost a bit, and JavaScript is starting to pickup.
(% change is more informative than “what is popular *today*” searches)

Indeed.com, “one search, all jobs”: http://goo.gl/H6Ialq
Relative growth *rates* (% changes):
#1: Objective-C in the lead (because of Mac and iOS development probably)
#2: C#
#3: VB (probably due to MS office [there's a lot of need for this in the business world for MS office situations])
#4: Java (getting less important line-of-business apps, most likely due to C# being easier and faster to work with using the MS tools).

Finally, GitHub repository details: https://goo.gl/k41JZN

According to Github, in 2008, Java was losing out (#7 place). C# would have overtaken it by now (or at least come close), except in 2008 onwards (as the Android Phone was getting popular) Java (for the PHONE) got popular (not desktop and web). The statistics today group the phone and web/deskop development statistics together. If you subtract mobile devices, then Java would lose (stay or fall from #7 position). This means 2008 shows the state of the “business world” as far as Java is needed for *enterprise apps* (non-mobile). As ES6/7+ (JavaScript) becomes the best cross-platform web, desktop, and mobile development platform, it will become the language of choice globally in the future, and THAT is the biggest trend of all. ;)

So, since JavaScript is now becoming king, there exists some transcoding languages used to make developing in JavaScript a lot easier. The contenders are TypeScript, Dart, and CoffeeScript. Of all three, TypeScript is the top, and soaring (https://goo.gl/BmMg3i).

Soon, even those may also not even be needed as much: http://www.wintellect.com/devcenter/nstieglitz/5-great-features-in-es6-harmony

Posted By: James
Last Edit: 26 Aug 2015 @ 07:58 PM

EmailPermalinkComments (0)
Categories: Coding
 19 Aug 2014 @ 6:00 PM 


What web related programming language is your favorite?  There are so many options these days, between Java, JavaScript, Go, Dart, PHP, Phython, Ruby, .NET/Mono, and more – enough to spin the heads of many new developers on the scene.  So, which should you chose to learn if you are starting out?  First off, let me just say that I think it’s a BAD idea to start at a high level language that does everything for you (except, perhaps, as an introduction to get one’s “hands wet”).  Why?  Because you cannot truly understand what is going on behind the scenes.  In my 30+ years of development experience, I can honestly say that I have only truly mastered that which I have truly understood.  Abstraction is not always a good thing, unless it’s sole purpose is to help speed up development, and not used to code in ignorance.  To this end, I’d want a good middle ground in development – not too low level (machine code anyone?), and not too high level (VB?).

The Baseline

I have tried many languages to date (I started with BASIC as a kid [C64, yeah baby!], then assembly [started on the C64], C/C++, Java, C#, etc.), and regarding the JS++ languages (a term coined for languages the transpile down to JavaScript) I never really felt that any of them seemed right (concept and/or syntax wise).  Yes, they can save time, but I never felt they could scale very well (or maybe I just never felt at home).  I even CREATED my own scripting language called ASM Script (assembly-like script, but much easier), and even used it on an application project that eventually won a $475k RFP for a company, and also for scripting a 3D editor tool for a 3D library years back; however, would the world really accept it in the long run? After some thought, I realized that what was needed is:

  1. * A scalable script (for large modular enterprise applications).
  2. Compiles to local device machine code.
  3. Has garbage collection.
  4. * Is known and used world wide by the greatest number of developers.
  5. Is an open world-driven standard (driven by multiple “big players”, not run by ONE company [open source or not]).
  6. Flexible/dynamic, but with type constraints where needed.
  7. * The same code base can be used both server and client side without needing to learn two separate languages.

At first I though that, well, since JavaScript is JIT compiled now, why not use that?  It must be fast enough now for most apps.  The problem at the time was with #1 above – I just could not see it scale well for large modular applications without creating a huge mess.  I also considered GO and Dart, but I could just never see it being used *world wide* by all company devices/computers, browsers, etc. (Microsoft will never bend to it for one).  I mean, for example, GO was created for use with internal Google development teams, in efforts to write code needed for the kind of collaboration and scalability needed by Google for their servers and other software (the video on the front page of the website [at the time of this writing] even states that fact).  This does not mean that it will translate to being useful by everyone.  For example, Microsoft has their own internal process with .NET and TypeScript (TS is open source as well), Oracle (Java) has theirs, many others use SAP (an ERP system used by large companies) with uses Java and ABAP, and I’m sure you could think of a dozen more.  Why should all companies use the mighty Google GO language, or even Dart?  The simple answer is that every language has a good and bad side, and what works for some, does not always work for others.  For all time, this will always be the case.  A language is a tool, and as more mature developers would agree, you use the right tool for the right  job – and also, learn to change with the times as needed.

The Powers That Be

Now, all that said, there’s also the idea of “momentum”.  If you stood in front of a fast moving train, how much would you slow it down? ;)  Did you know, by now, we could all be driving electric cars? (http://goo.gl/41IV2c)  But, the “powers that be” didn’t want to let go of the oil sales. As well, many claim it would have caused economic trouble (mechanic job losses, etc).  While the important thing is to invest in a better future, it’s the big players with the power that ultimately shape the future.   The electric car, being ahead of it’s time, was too “disruptive” in many ways, and was squashed for a time.  The goal then was to later focus on a “hybrid” idea that would help bridge the gap.  Why?  Because a good middle ground is almost always a good compromise of one’s terms (like arguing married couples ;) ).  For a good web based language standard to succeed it needs to have GLOBAL momentum.  As well, it cannot be proprietary – the moving force must be with the people.  Of the two major contenders, Dart tries to be it’s own thing, while TypeScript does not (TS emulates the upcoming ECMAScript 6 standard).  This is why Dart will never be adopted – simply because 1. it’s trying, in arrogance, to be a replacement for JavaScript, and 2. Microsoft won’t allow it as a standard.  JavaScript is the only thing Google and Microsoft can agree on because, frankly, it’s on neutral grounds.  It’s like the mediator between feuding couples. ;)  The focus then should be to slowly bring JavaScript to where it needs to be, not fragment the web with everyone else’s own language ideas.

The Mess

So, let’s make the picture a bit more clear: Google has Go/Dart/JS, Microsoft and Stack Overflow uses C#/VB.NET/JS, Oracle/eBay/Linkedin uses Java/JS, Facebook uses a big variety :) , Yahoo/Wikipedia/Wordpress uses PHP/JS, Blogger uses Python/JS, Bling (Microsoft) uses ASP.NET/JS, and so on (http://goo.gl/m4Re0). It’s also important to note that many big companies use large  ERP systems, such as SAP (which uses a proprietary scripting language called ABAP), and Oracle ERP. So, what do all these big players have in common?  They all develop for browsers and mobile devices.  And what do all mobile devices and browsers support? JavaScript.  But is JavaScript scalable?  Not easily.  But … there is light coming at the end of that long tunnel.

Working Together

JavaScript is the only language that has forced companies to learn to work together for a single code base.  Back in the browser war days, the lack of standards compliance and diverse interpretation of implementation details attributed to many developer headaches (mine included).  I even gave up on JavaScript for a few years because of it (after creating a large library for a web based game development IDE).  It wasn’t until over a couple years back that I noticed a shift occurring. The new HTML5 tags, along with the new ECMAScript 5 & 6 standards, is changing the way JavaScript is viewed regarding its use for application development.  In fact, HTML5 is supporting “off line” applications, using such things as Web Storages, Web SQL, “app.manifest” files, file system APIs, and more.  This means that you could create non-server based, client only, applications that can save locally.  As Microsoft gets its act together with IE standards compliance, and plays nice with the other boys in the sandbox, along with Apple supporting the HTML5 application model, we will see more and more of desktop (and native mobile) style applications being built on the web.  Regardless of JS++ type languages (Google Dart, Coffescript, etc.), in the end it all transpiles down to JavaScript.  With language levels, the higher up you go (i.e. closer to “human speak”), the less control you may have, but the faster you can work.  On the flip side, the lower you go, the more power you have, but the longer things take to develop.  If we consider that  JS++ languages transpile down to JavaScript, which in turn becomes JIT (just-in-time) compiled (to machine code), we can see the “middle” ground here might be JavaScript itself, and is the common language already adopted cross-platform by all major corporations. The vendors are diverse, and hardware is diverse, but JavaScript is not (the compromise). Since we can’t force the world to adopt a new language overnight, we should be fixing up JavaScript into something better (because it’s already adopted), and not confuse people with new stuff.  Also consider, what if something in a JS++ language didn’t work out for some reason?  You’d most likely have to review the resulting JavaScript to see what the heck is going on – so, why not just learn JavaScript to begin with?  Well, there are issues again with the language quirks and scalability, but this is changing! …

The Future

The ECMAScript standards people have been busy little bees (or ants?), moving us towards a better future, and a richer web experience.  I envision that those in the future who master the new semantics will truly understand what is going on in their code, and will be the top of the line, and obtain a skill transferable to any organization (trade security). As well, organizations that focus on popular cross-platform languages will have no problems finding a replacement for developers working on high priority/critical development projects.  The new ECMAScript 6 standard introduces concepts similar to many OOP type languages, like classes, properties, modules, iterators, and much more. Now, if only JavaScript could add static typing, then the compiler could catch errors early on, making enterprise development much easier.  Well, in fact, there is such a thing.  Keeping to the true nature of ECMAScript 6, and allowing the use of static typing, along side dynamic types, TypeScript is the only language I know that accomplishes this (and addresses ALL points in my list at the top).  In fact, TypeScript is not even a “new” language.  It’s just ECMAScript 6 made available TODAY, with optional type checking added (similar to ActionScript, which is also popular, so flash developers will be right at home).  Even the compiler itself is created in JavaScript!  This opens a whole new set of doors (in-browser based IDEs, etc.).  When used along with JavaScript supported servers (like NodeJS), it allows enterprise applications to reuse code between client and server side development, greatly reducing the developer workload (for instance, using JavaScript to validate user input client side before sending, and server side as well [using the same code] for more secure validation).  TypeScript already supports NodeJS (a JavaScript server), and there are JS libraries, such as V8.Net, which can be used to build custom servers scripted using JavaScript.  It’s worth noting that Microsoft is positioning JavaScript as a tool for building windows apps (and supports JS servers for mobile apps with Azure using NodeJS), Apple is going to support WebGL iOS 8 (great for game companies!),  rich media apps will be able to use WebRTC, Away3D (a popular 3D flash library) is moving to HTML5/JavaScript via TypeScript, and the list goes on.


So, to make it clear, I’m not advocating the use of TypeScript.  I’m advocating the move to mold JavaScript (ECMAScript) into what it needs to be.  It’s like the marriage that brings the warring kingdoms together, and declares peace across the land. In time, JavaScript will become a powerful language, and perhaps even TypeScript will become obsolete.  Until then, TypeScript gets us there today.

Keep in mind, this is MY personal blog, and it’s how I see things.  You may disagree – in which case you can write your own. ;)  I traverse life with an open mind though, so I don’t mind hearing other view points on the matter.

Too see more on TypeScript, watch this video, or visit the  website.

Note: I have no affiliation with Microsoft, and after much research, made these decisions entirely on my own, in light of my past experiences.

Some stats:


BTW:  Yes, I’m aware that “Go” is not really intended as a client side JS++ language, but I put it there anyhow for curiosity sake.

Posted By: James
Last Edit: 19 Aug 2014 @ 06:04 PM

EmailPermalinkComments (0)
Categories: Coding
 17 Oct 2012 @ 11:50 PM 

I work in Healthcare and it blew my mind when I found out that a developer hired by a hospital (already a no-no) developed software using MongoDB for an enterprise database for relational type data. To make matters worse, they were attempting to remake existing software which already had relational data! I think it was a cheap compromise because it made one aspect of their issue “go away”. What was it? SPACE. It wasn’t even an issue! There were over 200 fields in the original table, and their idea was “well, if we only use some of the fields, then we can save space.” :( They, however, failed to realize that almost ALL the fields get filled out DURING THE COURSE OF THE PATIENT’S THERAPY.

Why is this stupid? Consider this database table:

FirstName   LastName
John        Doe

and now this MongoDO record:


The characters in the table above would only be 7, plus 1 or 2 bytes for length for each column, so perhaps 9 (for varchar(50), UTF-8). The second example would be the characters as shown: 29!

So … where is the space savings? There is none (unless a case gets cancelled or something). To make matters worse, MongoDB is NOT SUPPORTED natively by most reporting software. Many hospitals have report writers, and they will not be able to work well with it (for ad-hoc reporting). To make matters even WORSE AGAIN, there are few DBAs (and none in most places) who even know what to do with it. Also, what about renaming columns? You’d have to update every record!!! What about trigger events, special stored procedures, and transactions!? Nothing.

Don’t be stupid or lazy, and don’t put databases back to the stone ages – and if anyone tells you “but it scales!”, just picture a big “L” on their forehead from now on. Just stick with more efficient databases that have evolved over the decades – which CAN also scale in their own way (see here and here).

Posted By: James
Last Edit: 01 Nov 2012 @ 10:36 PM

EmailPermalinkComments (0)
Tags: ,
Categories: Coding, Databases
 19 Aug 2012 @ 12:03 AM 

First, before I begin, let it be known, I love Silverlight, and I plan to keep developing in it (visit my site here at jamonjoo.com).  That said, I don’t know why I have the feeling that all this Silverlight stuff is a ploy to get developers onto Windows 8, which just so happens to be XAML based; I hope I’m wrong.  All I can say is if Silverlight becomes a “Microsoft-Device-OS-Only Cross-Device Platform” [say that 5 times fast], then it will confirm my suspicion. I can only hope that Moonlight will start supporting multiple OS’s and devices also in time, and perhaps that may be a saving grace (and perhaps Microsoft should help it do so – it would only work in their favor), but I wouldn’t hold my breath.  Honestly, the whole thought of having to resort back to HTML/JavaScript makes me feel a bit feral.  I have yet to see companies cooperate with standards; even in healthcare HL7 interface communications (I’ve done a lot of work in software development for Healthcare).  The only true way to build something to run across multiple systems, devices, etc., and have it look/run the same everywhere is NOT by standards, but to either 1. Have a single company create and maintain the development platform (tainted sometimes by money and politics), or 2. Built it open source by the community (which will probably lack somewhat in quality and coherency (due to volunteers), and good development tools).

Of course, the other “SMART” thing MS could do (and may be doing [see: http://bit.ly/NLo0jm]) is to continue to have SL as a means to run software cross-platform, while also supporting XAML/C# apps it in all their own platforms.  This might attract many developers to the Microsoft platforms, knowing that they can also easily have versions to run on other non-MS platforms as well (which I assumed SL was going all along a few years back).

In conclusion, if SL doesn’t work out, then I’m creating my own, and HTML/JS can [insert vulgar statement here] … anyone else on board!? LOL ;)

All that said, I suppose also, in time, if SL5 gets deployed with Windows 8 – along with the increase in XAML/C# apps, and the market place – and since SL5 I’m sure will be around for quite some time, there’s a good chance there will be a future time when SL5 (at the very least) will still be a great platform to use, since it may be on the majority of computers around the world (http://bit.ly/8l4Y9Q). Honestly, I’m still optimistic in any case. ;)


Posted By: James
Last Edit: 19 Aug 2012 @ 05:02 PM

EmailPermalinkComments (0)
Categories: Silverlight
 30 May 2012 @ 3:58 AM 

I have have a solution that works really well for those who need to know when a child element is added or removed within their custom control. The ‘Children’ property is actually found by the parser using the “ContentProperty” attribute, and I think it’s inheritable. Anyhow, if you simply put this in your derived class:

new public ObservableCollection<UIElement> Children { get { return _Children; } }
readonly ObservableCollection<UIElement> _Children = new ObservableCollection<UIElement>();

Then all the added elements will now go to this new collection instead! :) All you have to do it listen to the “CollectionChanged” event.

Posted By: James
Last Edit: 17 Jun 2012 @ 04:01 AM

EmailPermalinkComments (0)
Categories: Coding, Silverlight
 11 Jul 2010 @ 1:35 PM 

In my solution, I have a Silverlight application using WCF services and a single DataModels.cs file with contents similar to the following. The only thing to remember is to add the WindowsBase reference to your WCF service project in order to use the same ObservableCollection<> template object.
(in my case, I put DataModels.cs in the WCF project, and created a virtual file link to it from the Silverlight project)

This is a sample of the code I use:
____________________________________________________ ____________________________________________

// <...other using statements...>
using System.Collections.ObjectModel; // ObservableCollection<> is added via WindowsBase (WindowsBase.dll).

public partial class CPPLoginState
    public bool Ok { get; set; }
    public string UserName { get; set; }
    public Int32 UserID { get; set; }
    public ObservableCollection Roles { get; set; }
public partial class CPPLoginState
    public CPPLoginState()
        Ok = false;
        UserName = "";
        UserID = 0;
        Roles = new ObservableCollection();


The trick here is in the Silverlight proxy’s use of the “partial” modifier for it’s class definitions. This allows “adding” code to them. :)

I must say, it only took one week working with Silverlight (from knowing nothing, not even WPF) and I’m almost done with a fairly complicated control library and host application. Silverlight + WCF really does == RAD development. :D

Posted By: James
Last Edit: 13 Jul 2010 @ 01:35 AM

EmailPermalinkComments (0)
Tags: , ,
Categories: Silverlight
 11 Jul 2010 @ 3:36 AM 

So, you have two projects: WCF & Silverlight, and put a break point on code in a shared class between the two projects. Visual Studio breaks on the line, but as soon as you hit F10 or F11, the code simply “continues” as if to ignore your step request.

This very scenario really messed with me for a few months, and the reason I didn’t investigate much at the time was because I could simply create many breakpoints and run between them. Recently, however, I had code too complex to keep doing this without pulling my hair out, so I investigated again and suddenly got an idea regarding meta data. Perhaps there’s an option preventing this from working on the “root” class. You see, Silverlight-side service references create classes from server side data types (where specified), and my shared code was using partial classes to add methods to both sides (server and client). The problem is that the shared code file isn’t decorated with meta data tags, but the auto-generated client-side code IS, and in fact, this was the line:


So, I did a “replace all” to clear all occurrences and presto! My life just got a little better. ;)

Posted By: James
Last Edit: 13 Jul 2010 @ 01:36 AM

EmailPermalinkComments (0)