Why use Ruby on Rails

1. Ruby on Rails is perfect for quick prototyping, fast iterations, and smaller applications.

Notes for improving code quality and avoiding problem

1. please make sure if you pass a ReportCriteria object to a method, you don't modify that criteria in the method. Because it is a reference object, that will affect all other methods that use that criteria. If you do need to use the modified criteria (for example to re-run a LI query with a different location), you a cloned copy of the criteria.

JavaScript IIFE & function pxpression / function declarations

https://www.sitepoint.com/demystifying-javascript-closures-callbacks-iifes/

http://stackoverflow.com/questions/20267957/how-do-i-debug-a-callback-function-used-in-a-jquery-bind-call-with-chrome-devt

http://stackoverflow.com/questions/11788081/chrome-javascript-debugger-breakpoints-dont-do-anything

http://kangax.github.io/nfe/

Linux / Mac Command Hack

1. Read MANIFEST.MF file of a .jar file

$ unzip -q myarchive.jar META-INF/MANIFEST.MF

2. Show public IP for my laptop
    1) dig

1 2	dig o-o.myaddr.l.google.com txt @ns1.google.com +short nslookup -type=txt o-o.myaddr.l.google.com ns1.google.com

"10.11.12.13"
OpenDNS:

1 2	dig myip.opendns.com @resolver1.opendns.com +short nslookup myip.opendns.com resolver1.opendns.com

10.11.12.13
Akamai:

1 2	dig whoami.akamai.net. @ns1-1.akamaitech.net. +short nslookup whoami.akamai.net. ns1-1.akamaitech.net.

10.11.12.13
other usage

1 2	dig o-o.myaddr.l.google.com txt nslookup -type=txt o-o.myaddr.l.google.com

returns txt record of DNS request to authoritative source address
edns0-client-subnet if available, showing original DNS request source address

1 2	dig o-o.myaddr.l.google.com txt @8.8.8.8 +short nslookup -type=txt o-o.myaddr.l.google.com 8.8.8.8

"198.51.100.1"
"edns0-client-subnet 203.0.113.0/24"

    2) curl

curl ifconfig.co 

 

Java Spring, JPA Useful materials, problem-solution

1. JPA Tutorial
http://www.java2s.com/Tutorials/Java/JPA/index.htm

2. Spring RestController doesn't set parameter for PUT request
FROM:
http://stackoverflow.com/questions/29017593/spring-4-restcontroller-not-receiving-data-from-put-request

This is a limitation of the Servlet Spec and the inner workings of Spring for populating model attributes.

First, the spec says

3.1.1 When Parameters Are Available

The following are the conditions that must be met before post form data will be populated to the parameter set:

1. The request is an HTTP or HTTPS request.
2. The HTTP method is POST.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has made an initial call of any of the getParameter family of methods on the request object. If the conditions are not met and the post form data is not included in the parameter set, the post data must still be available to the servlet via the request object's input stream. If the conditions are met, post form data will no longer be available for reading directly from the request object's input stream.

Second, your handler methods' second parameter, the one of type Note, is actually considered a model attribute, as if it was implicitly annotated with @ModelAttribute. As such, it is processed by Spring's ModelAttributeMethodProcessor. This HandlerMethodArgumentResolver uses the getParameter (and its family of methods) for populating the created instance's fields.

Since this is a PUT request, the parameters are not retrievable through getParameter. However, they are still accessible through the request body, but Spring doesn't go there for model attributes.

You can do the conversion yourself. But I suggest you change your request content to JSON or XML for PUT and use @RequestBody annotated parameters.

---

There is a long standing request to add parameters for PUT requests.

Javascript confusions and tricks

1. Console.log output of an array of objects VS an array of primitive value
Console.log output of objects is a pointer, not real value.
For example:

var array = [1,2,3,4,5,6,7,8,9];
console.log("start");
for(var i = 0; i < array.length; i++){
  console.log(i + " = " + array[i]);
  console.log(array);
}
console.log(array);
console.log("end");
array.push(9999);

The result out put is:

start
0 = 1
[1, 2, 3, 4]
1 = 2
[1, 2, 3, 4]
2 = 3
[1, 2, 3, 4]
3 = 4
[1, 2, 3, 4]
[1, 2, 3, 4]
end

But the output of this:

var array = [{value:1},{value:2},{value:3},{value:4}];
console.log("start");
for(var i = 0; i < array.length; i++){
  console.log(i + " = " + array[i]);
  console.log(array);
}
console.log(array);
console.log("end");
array.push({value:9999});

is:

start
0 = [object Object]
[Object, Object, Object, Object]
  ->0: Object1:
  ->1: Object2:
  ->2: Object3:
  ->3: Object4:
  ->4: Object
        value: 9999
         ->__proto__: Object
         length: 5
         ->__proto__: Array[0]
1 = [object Object]
[Object, Object, Object, Object]
2 = [object Object]
[Object, Object, Object, Object]
3 = [object Object]
[Object, Object, Object, Object]
[Object, Object, Object, Object]
end

Repost: Fire and Motion

Original Post: http://www.joelonsoftware.com/articles/fog0000000339.html

Joel on Software

Fire And Motion

by Joel Spolsky

Sunday, January 06, 2002

Sometimes I just can't get anything done.

Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn't happen.

These bouts of unproductiveness usually last for a day or two. But there have been times in my career as a developer when I went for weeks at a time without being able to get anything done. As they say, I'm not in flow. I'm not in the zone. I'm not anywhere.

Everybody has mood swings; for some people they are mild, for others, they can be more pronounced or even dysfunctional. And the unproductive periods do seem to correlate somewhat with gloomier moods.

It makes me think of those researchers who say that basically peoplecan't control what they eat, so any attempt to diet is bound to be short term and they will always yoyo back to their natural weight. Maybe as a software developer I really can't control when I'm productive, and I just have to take the slow times with the fast times and hope that they average out to enough lines of code to make me employable.

     

What drives me crazy is that ever since my first job I've realized that as a developer, I usually average about two or three hours a day of productive coding. When I had a summer internship at Microsoft, a fellow intern told me he was actually only going into work from 12 to 5 every day. Five hours, minus lunch, and his team loved him because he still managed to get a lot more done than average. I've found the same thing to be true. I feel a little bit guilty when I see how hard everybody else seems to be working, and I get about two or three quality hours in a day, and still I've always been one of the most productive members of the team. That's probably why when Peopleware and XP insist on eliminating overtime and working strictly 40 hour weeks, they do so secure in the knowledge that this won't reduce a team's output.

But it's not the days when I "only" get two hours of work done that worry me. It's the days when I can't do anything.

I've thought about this a lot. I tried to remember the time when I got the most work done in my career. It was probably when Microsoft moved me into a beautiful, plush new office with large picture windows overlooking a pretty stone courtyard full of cherry trees in bloom. Everything was clicking. For months I worked nonstop grinding out the detailed specification for Excel Basic -- a monumental ream of paper going into incredible detail covering a gigantic object model and programming environment. I literally never stopped. When I had to go to Boston for MacWorld I took a laptop with me, and documented the Window class sitting on a pleasant terrace at HBS.

Once you get into flow it's not too hard to keep going. Many of my days go like this: (1) get into work (2) check email, read the web, etc. (3) decide that I might as well have lunch before getting to work (4) get back from lunch (5) check email, read the web, etc. (6) finally decide that I've got to get started (7) check email, read the web, etc. (8) decide again that I really have to get started (9) launch the damn editor and (10) write code nonstop until I don't realize that it's already 7:30 pm.

Somewhere between step 8 and step 9 there seems to be a bug, because I can't always make it across that chasm. For me, just getting started is the only hard thing. An object at rest tends to remain at rest. There's something incredible heavy in my brain that is extremely hard to get up to speed, but once it's rolling at full speed, it takes no effort to keep it going. Like a bicycle decked out for a cross-country, self-supported bike trip -- when you first start riding a bike with all that gear, it's hard to believe how much work it takes to get rolling, but once you are rolling, it feels just as easy as riding a bike without any gear.

Maybe this is the key to productivity: just getting started. Maybe when pair programming works it works because when you schedule a pair programming session with your buddy, you force each other to get started.

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can't fire at you. (That's what the soldiers mean when they shout "cover me." It means, "fire at our enemy so he has to duck and can't fire at me while I run across this street, here." It works.)  The motion allows you to conquer territory and get closer to your enemy, where your shots are much more likely to hit their target. If you're not moving, the enemy gets to decide what happens, which is not a good thing. If you're not firing, the enemy will fire at you, pinning you down.

I remembered this for a long time. I noticed how almost every kind of military strategy, from air force dogfights to large scale naval maneuvers, is based on the idea of Fire and Motion. It took me another fifteen years to realize that the principle of Fire and Motion is how you get things done in life. You have to move forward a little bit, every day. It doesn't matter if your code is lame and buggy and nobody wants it. If you are moving forward, writing code and fixing bugs constantly, time is on your side. Watch out when your competition fires at you. Do they just want to force you to keep busy reacting to their volleys, so you can't move forward?

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don't have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire. They go into their customers and say, "OK, you don't have to buy from us. Buy from the best vendor. But make sure that you get a product that supports (XML / SOAP / CDE / J2EE) because otherwise you'll be Locked In The Trunk." Then when the little companies try to sell into that account, all they hear is obedient CTOs parrotting "Do you have J2EE?" And they have to waste all their time building in J2EE even if it doesn't really make any sales, and gives them no opportunity to distinguish themselves. It's a checkbox feature -- you do it because you need the checkbox saying you have it, but nobody will use it or needs it. And it's cover fire.

Fire and Motion, for small companies like mine, means two things. You have to have time on your side, and you have to move forward every day. Sooner or later you will win. All I managed to do yesterday is improve the color scheme in FogBUGZ just a little bit. That's OK. It's getting better all the time. Every day our software is better and better and we have more and more customers and that's all that matters. Until we're a company the size of Oracle, we don't have to think about grand strategies. We just have to come in every morning and somehow, launch the editor.