Sunday, May 31, 2015

Love the Stateless Nature of the Web and Be Happy

Hi,

(This is a technical article about the history of web programming. It may prove interesting to a non-programmer, however.)

The stateless nature of the web is the key to happiness as a developer.

By stateless, I mean that one web page without effort on the part of the programmer (or effort on the part of the framework the programmer is using), does not remember or recall anything when you go to the next web page.



(HTTP is the foundation for web programming, not Framework A or Language B or Abstraction C)

Most programmers did not become programmers to do "plumbing" or "wiring". Most programmers have passions like solving deep technical problems or algorithms or just getting things to work. Most problems do not like solving trivial issues. "Hooking things up" for example, moving data from point A to point B is not why most programmers got degrees or experience or spend their hours late hacking away. But it is exactly the thing to embrace, to master and to be happy with for professional success and personal satisfaction.

And indeed, frameworks and platforms attempted to abstract away the plumbing and mundane tasks and impose a stateful model to increase programmer productivity and still do. For example, the ASP.NET Webforms technology abstracted away the nature of the web. It continued and continued and continued until Microsoft saw the light and created ASP.NET MVC. MVC isn't new pattern. It's been around for decades (or so I've been told). But Microsoft abandoned its page lifecycle model in favor for the loosely coupled MVC model because they finally saw the light.

Moving data from point A to point B is exactly the key to happiness as a (web) developer in every way. Accept the stateless nature of the web as the fundamental problem, and all the fun and wonderful things happen to your life and career.

Those who embraced the stateless nature of the web, and did so from top to bottom, faced success in the past fifteen years. Those who ignored the stateless web, suffered, unless they were lucky. One obvious example is MySpace versus Facebook. ASP.NET Webforms is great, and was good for its time. It allowed COBOL or C programmers to transition to web programming with very little effort or investment of time upfront to learn but more importantly accept the nature of the Internet.



(Courtesy of Google Trends)

But we all know what happened to MySpace. This is not a knock on Microsoft at all. I happen to like and love Microsoft, and like and love Linux as well. But, eventually Microsoft arrived to the same conclusion that everyone else did; that the stateless nature of the web can only be avoided so long until you pay the price.

No matter what frameworks come and go, no matter what technology comes and goes, the web will always be stateless. You've got a few choices.

  • Fight this. Draw a line and refuse to accept this, much less like it. Ignore how the Web works and the Internet works. Use frameworks, use abstractions, use layers, use everything and anything to ignore the fact that you need data to move from point A to point B but more importantly understand how that works. One day, the world will catch up (if it hasn't already). Out of all the options, this is the only one which ultimately leads to failure 100%. Better to get another career.
  • Fight this, but in an old fashioned way. This means mingling the client-side and server-side together to the point moving data from point A to point B is trivial. For example, avoiding strict Model-View separation and rendering everything all at once so everything is accessible to you all at once. An example of this is using technology which mingles the model and view, for example PHP, or the old ASP.NET Webforms. If you can handle spaghetti code or messy code, this is the way for you.
  • Fight this, but in a modern way (2015). This means using modern or cutting edge techniques like client-side JavaScript applications (so-called single page JavaScript applications). Bring order to chaos with frameworks like Backbone.js to keep data squarely on the client side except when absolutely necessary. But eventually, you will need to move data to the server. The problem is just being pushed off until later.
  • Accept this. Work the way the Web was intended. This can take several forms.
    • Create a mini-framework to move data from point A to point B. This does not have to start from scratch. For example, you could make AJAX requests with jQuery instead of raw JavaScript (and should). The key point is to not depend on state when moving between webpages. The disadvantage of this approach is 
    • Use someone else's gargantuan framework to move data from point A to point B. Use only the features you want, when you want them, and keep an eye on performance. However, the risk is one day the framework is obsolete, or the framework's designers or implementers don't have the same vision for you or your best interests at heart. 
    • Work at a very fundamental level right with bare HTTP. Become a master at DOM manipulation, become a master at JavaScript and learn the cross-browser differences (or at the least have caniuse.com handy). Working at this level, you will never become dated or obsolete. The problem with working at this level is speed. Can you create deliverables as fast as the guy who uses Framework of the Day to crap things out faster than you can blink? 
So, there are many choices available for those who want to develop for the web. Which one will you choose? Which one will make you happy? That is a question only you can decide.






Sunday, May 24, 2015

MySQL Stored Procedure Not Using IN variable

Hi,

I came across a trivial problem in MySQL today. I hope this helps someone (should apply to Oracle and MS SQL as well).

When defining a MySQL stored procedure and executing it, instead of the correct result set I got all rows of the table.

DELIMITER //
CREATE PROCEDURE testproc
(
  IN id INT
)
BEGIN
  SELECT *
  FROM `Test`
  WHERE `ID` = id;
  END //
DELIMITER ;

On closer inspection in phpMyAdmin and fooling around with the definition of the stored procedure, I discovered the issue. The column is called id, and of course id is always equal to id. It doesn't resolve to the IN variable id.

On further thought, this makes sense. Scope should be the smallest possible, and if one defines an IN or OUT or INOUT variable the same as a column name, there be dragons.

See the following for more information:
https://dev.mysql.com/doc/refman/5.7/en/local-variable-scope.html (local variables)
https://dev.mysql.com/doc/refman/5.1/en/set-statement.html (session variables)


Tuesday, May 19, 2015

PyCharm Interactive Command Line / Debugger

Hi,

Didn't find this on Google so here it is.

If you are looking for the Interactive Command Prompt when you are debugging for the PyCharm Python IDE Community Edition (the open source free version) go to Tools -> Open Debug Command Line. Somewhat hidden since you would expect it to be under the Debug menu.

















Other answers I found told me to click on a non-existent icon on the Debug Toolbar, which either doesn't exist in the Community Edition or was moved / removed.

Hope this helps someone.

Saturday, May 16, 2015

jQuery AJAX 500 Error with ASP.NET MVC

Hi,

Just wanted to drop a quick note for anyone using jQuery with ASP.NET MVC and experiencing 500 Internal Server errors when debugging with the browser's network monitoring feature.

In order to send a proper AJAX call with jQuery's $.ajax function, you must use JSON.stringify . Suppose you are sending one field to the MVC backend.

var data = $('#inputBox').val();
$.ajax({
  method: "POST",
  url: "@Url.Action("ActionName", "ControllerName")",
  data: JSON.stringify({"data" : data }),
  success: function (data) {
    if (data.valid)
    {
        alert('Success:' + data.message);
    }
  }
});

In the ControllerName controller,

public JsonResult ActionName(string data) {
  // do something with data
  return Json(new { valid = true, message = "Success" });
}

Basically, if you receive a 500 error from the server but are never able to hit a break point in Visual Studio, look at the way the data is sent and the way the data is received. More likely than not there is an error with the data or dataType or mimeType parameters (cross-domain requests are a different beast too).

The key difference is the difference between a JSON string and a JavaScript object. JSON strings aren't JavaScript objects just because they look like JavaScript objects; they have a stricter syntax. It is not a limitation or error of ASP.NET MVC or the backend if it refuses to parse incorrectly formed JSON.

Thanks for visiting and comments are welcome.