Tag Archives: programming - Page 2

To Bed To Rise

Posted by on March 5, 2013 No comments

When Windows 8 came out, I had planned on making a Windows Store app that would be an alarm clock with sound soother for falling asleep.  Hardly a new idea.  In fact, I was driven more by personal need than personal gain.  I have the Dell Inspiron Duo.  The original one, with the JBL audio dock.  It’s possibly the best-designed multifunction consumer device. The custom dock triggers an app that can be used as a slideshow (like on an office or counter, replacing a digital photo frame), or as an alarm clock (best kept bedside).  The point is, when you’re not using it as a laptop or tablet, you’re using it as something else.

Well, you may know that this product got justifiably poor reviews because of its weight/battery life ratio and isn’t in production or even in warranty anymore.  Regardless, I own one and I have two docks, one at home and one at work.  One day I decided to upgrade to Windows 8 and the clock app wouldn’t launch anymore.  This was heartbreaking for me.  And until a recent explosion of programming motivation, I just used the dock as a charging station.

But tonight is the first live run of my replacement app for the Inspiron Duo “DockClock” or “DuoStage” or whatever they called it.  I’m pleased that I was able to come up with a technique for detecting when the laptop was docked as well as discovering the method for putting the screen to sleep on command.  The rest, involving background sounds, alarm timing, and background animation was easy work.

The original:

image

My prototype, with corner controls displayed:

image

My main regret is that I waited so long to write this app, since there’s a lot of Duo owners out there that have probably lost their capability to use the alarm clock in their docks.  But once I’ve given it sufficient personal testing, I’ll put it out there for download.

Oh, and as a passing mention, it appears I’m in my fifth year of posting on this blog.  I sure didn’t expect that.  There’s a lot of history in here, with some really low points in my life. Despite that, I’d have to say that the present is truly a high point of my life.  Will there be another five years?  Who knows?

The Biggest and the Bloatedest III

Posted by on January 11, 2013 No comments

It seems to be the natural progression of things to become so big and so complex that they just become useless.  Then new upstarts that are simple and lean take over, until they become huge and the cycle continues.

At my job, we use custom controls for our website and application.  Custom controls have always been a great thing for developers because they give you extra functionality built in, so you don’t have to code it.  Telerik controls have been leaders in this field.  But recently, there have been changes – breaking changes – in the newer versions.

I had a simple RadTextBox that I added a script to so that it would do a postback when there was 5 numbers in the textbox (a zip code).  Simple and easy:

if (((event.keyCode||event.which)!=9)&&((this.value.length==5)||(this.value.length==0))) setTimeout("pnlUpdate",300)

This suddenly stopped working.  Well, the postback would happen, but the RadTextBox’s value would be blank.  Telerik support suggested I handle the control’s KeyPress event:

function KeyPress(sender, args) {
    var textLength = sender.get_textBoxValue().length;
    if (textLength >= 5) {
        sender.set_autoPostBack(true);
        sender.set_value(sender.get_textBoxValue());
    }
}

This is stupid enough, that I have to use a custom event and custom methods to get and set the value of a textbox, but there was more that needed done.  The event fires on the key press, but the textbox value doesn’t include that key yet, so you have to include it yourself when measuring the length.  But you have to insert the new character in the right position for when you set the RadTextBox value.  Finally, when using the KeyPress event, the RadTextBox’s MaxLength isn’t enforced, so there has to be a check included for that. 

So from the Telerik proposed solution, I ended up with a script like:

function checkZipCode(s, e) {
    var t, l, c

    c = s.get_caretPosition();
    t = s.get_textBoxValue();
    t = t.substring(0, c) + e.get_keyCharacter() + t.substring(c);
    l = t.length;
   
    if (l > 5) {
        e.set_cancel();
        return
    }

    if (l == 5) {
        s.set_autoPostBack(true);
        s.set_value(t);
    }
}

This is totally unacceptable.  And all because Telerik decided to begin managing the control’s state independently, breaking the standard HTML input behavior.  It’s been growing over time that a developer using Telerik controls has to do things “the Telerik way” in order for the controls to work properly.  Where Telerik controls once were written as extensions to existing controls, they have become total replacements, with little resemblance to the original controls they look like.

So, it’s going to be my recommendation to reduce our dependence on Telerik controls.  I doubt we’ll be able to get rid of the RadGrid, which has its own universe of functionality and weirdness, but when DropDownLists  are rendered as <ul> and TextBoxes don’t use the standard Input Value property, there’s something really wrong about that.  It’s garbage like this that makes MVC so appealing.  Put it this way.  If the big argument against WebForms is that it is trying and failing to make a WinForms model work on the web, then Telerik is taking a WebForms app that is acting like a WinForms app and trying to make it act like an AJAX website.  At that point, you might as well not use WebForms.

Technology Can Do That, So Let’s Not

Posted by on January 2, 2013 No comments

I wonder what technology is coming to and at the same time, I wonder if I’m just getting old.  I look at things that were normal for me at the peak of my programming days and wonder if older developers thought I was an idiot for doing things that way.  For example, did the old procedural programmers of old see object-oriented design as ridiculous, slow, and inefficient?  Maybe.  But OO programming is pretty much the standard now.

But for some reason, I am confused as to why implicit typecasting is suddenly “awesome".  We had that way back when in VB and Classic ASP and we were hated for it.  Then .NET came along and strong-typing became the thing to do.  Now we’re back to implicit typecasting and scripted languages just like we had with ASP.

But the thing that’s really got me confused is cloud computing, why everyone thinks it great to rely on someone else instead of relying on yourself.  I guess the argument is “they can do it so much better than we can, so why not let them.”  There’s no more building yourself up?  You have to start at the top?  Talk about immediate gratification.  That’s bitter old man talk, there.

At my job, a co-worker (thankfully not me) has an integration project using Amazon Web Services (AWS).  As best I can tell, it’s a web service that sits in front of a message queue system.  To be slightly vague about the project, our client sends us a request with a questionnaire.  We collect the responses to the questions and send each individual answer back to the client as a message via AWS.  This infrastructure was forced on us; not our choice.  So, my old-timey brain is thinking, “why must a unit of work (a completed questionnaire), be transmitted in discrete pieces when it needs to be a single unit on their end?”  The answer to this is “don’t worry about it.”  The reason is a new crazy programming concept: eventual consistency.  Apparently our client is so hip and modern, they are using both “the cloud” and “eventual consistency” in their application design.

Eventual Consistency is nothing new.  Airlines have been using it forever.  Did you lose your luggage?  Is it now five states away?  It will eventually get to you and everything will be fine.  FedEx started using it with SmartPost.  If you ever had something shipped via SmartPost, you could watch the package get shipped all over the country, but eventually it would get to you.  With every real-world application of Eventual Consistency, you are guaranteed to get what you want, but never sure when it will happen.  Why, in any case, this became an acceptable solution is beyond me.

To wrap this up, but to leave it with some final, head-shaking, “why is this acceptable” thoughts, here’s some of the documented guidelines when using Amazon Web Services:

  • When you make a request for new messages, you may only request up to 10 new messages at a time.
  • If you request 10 messages, you may not get 10.  You may get less than 10, even if there are more than 10 messages in the queue.
  • If there are a very small number of messages in the queue, you may get zero.
  • Despite the inability for AWS to deliver the messages you request when you request them, all of the messages are available for viewing through their control panel.
  • When you send a message, you get no acknowledgement that it was sent successfully.  If you did not get an error during sending, you assume it was sent successfully.
  • You have no idea if the message was delivered to the destination queue successfully.  You will only know when the receiver picks up the message, and that is send as an acknowledgement on another queue.  You must query that queue and match up the acknowledgements with your initial sent messages.
  • The acknowledgement queue has all the limitations of the aforementioned message requests.

This is true progress.