Tuesday, December 31, 2013

micro service - a new development paradigm?


Succinct description of what makes up a mircro-service. 

  • Each application only does one thing
  • Small enough to fit in your head
  • Small enough that you can throw them away
  • Embedded web container
  • Packaged as a single executable jar
  • Use HTTP and HATEOAS to decouple services
  • Each app exposes metrics about itself 

from this presentation 

Thursday, August 22, 2013

Friday, August 2, 2013

Continous Delivery



Great quicky intro...

http://fernandorubbo.blogspot.com.br/2012/07/continuous-delivery-why-you-should-be.html

Thursday, August 1, 2013

Agile for the lone developer

Practices adopted from Agile Teams:
  • Create clearly defined, small chunks of work (i.e., user stores)
  • Hold daily “standups” before starting work each day
  • Keep track of how long it takes you to do tasks and how many tasks get completed in a sprint
  • Communicate frequently with the client, to provide regular updates and product releases and solicit feedback and input

Friday, June 21, 2013

Common Red Flags in Java Development


Java developers with few years of experience can quickly figure out the description for the below red flags.
  • Use of == (rather than .equals) with References
  • Use of .equals (rather than ==) with Enums
  • Magic Numbers and Literal Strings
  • String Constants
  • Use of Java's "Goto"
  • Depending on Scope for Appropriate References of Variables of the Same Name
  • Mismatched equals(Object) and hashCode() Methods
  • Lack of Javadoc Comments
  • Implementation Details in Methods' Javadoc Comments
  • Comments in the Source Code
  • Implementation Inheritance (extends)
  • Dead Code
  • Commented Out Code
  • To-Do Statements
  • Compiler Warnings and IDE/Tool Warnings/Hints/Findings
  • Compiler Warnings and IDE/Tool Warnings/Hints/Findings Turned Off
  • Too Clever / Science Fair Projects / Over-Engineered / Premature Optimization               

For succinct description see the original post
 

Wednesday, June 12, 2013

Be aware of CSRF for Web Applications

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

How does the attack work?

There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:
POST http://bank.com/transfer.do HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100
However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:
http://bank.com/transfer.do?acct=MARIA&amount=100000
Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:
<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>
Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:
<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0">
If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser will still submit the request to bank.com without any visual indication that the transfer has taken place.

10 deadly sins against scalibility

  1. Slow Disk I/O – RAID 5 – Multi-tenant EBS. Use RAID 10, it provides  good protection along with good read and write performance. The design of RAID 5 means poor performance and long repair times on failure. On AWS consider Provisioned IOPS as a way around IO bottlenecks.
  2. Using the database for Queuing. The database may seem like the perfect place to keep work queues, but under load locking and scanning overhead kills performance. Use specialized products like RabbitMQ and SQS to remove this bottleneck.
  3. Using Database for full-text searching. Search seems like another perfect database feature. At scale search doesn't perform well. Use specialized technologies like Solr or Sphinx.
  4. Insufficient Caching at all layers. Use memcache between your application and the database. Use a page like cache like Varnish between users and your webserver. Select proper caching options for your html assets.
  5. Too much technical debt. Rewrite problem code instead of continually paying a implementation tax for poorly written code. In the long run it pays off.
  6. Object Relational Mappers. Create complex queries that hard to optimize and tweak.
  7. Synchronous, Serial, Coupled or Locking Processes. Locks are like stop signs, traffic circles keep the traffic flowing. Row level locking is better than table level locking. Use async replication. Use eventual consistency for clusters.
  8. One Copy of Your Database. A single database server is a choke point. Create parallel databases and let a driver select between them.
  9. Having No Metrics. Visualize what's happening to your system using one of the many monitoring packages.
  10. Lack of Feature Flags. Be able to turn off features via a flag so when a spike hits features can be turned off to reduce load.

link: http://highscalability.com/blog/2013/6/10/the-10-deadly-sins-against-scalability.html

Tuesday, May 14, 2013

The 14 characters you meet as a coder

great post borrowed from here
I am sure I fit somewhere in here......
The Developer Diva. 
The Rock Star.
Generally this guy knows HTML and JavaScript or maybe PHP, but from the ego you'd think he just set down his Les Paul after headlining at Madison Square Garden. After his 15 minutes are up, the crashing ego isn't pretty.
The Reluctant Programmer.
Rather than urge their kids to be doctors or lawyers, some parents push their progeny to go into software development. Sometimes it works out. And sometimes the poor, benighted offspring gaze out of the office window yearning for hard labor in the 95-degree heat -- anything except spending their lives doing something they don't want to do, whether or not they have the aptitude for it. Usually their work is mediocre, and they're out the door every day at 4:55 p.m. sharp.
The Holy Priest.
This person revels in technology for its own sake and has no patience for the hapless techno weenies who don't spend their days chanting arcane invocations using terms like "regex," "SOAP," "asynchronous messaging," "n-tier architecture," and "CORBA." Holy Priests recognize opinions as valid only if they come from fellow clerics, and they express contempt for "lusers" at every opportunity. They may be brilliant coders, but keep them locked in the closet, far away from customers.

The Process Guru.
You might wonder who would spend all their time reading books on the latest development methodologies. That would be the Process Guru, who knows more about Scrum, XP, RUP, Crystal, PSP, TSP, and COCOMO than the rest of your organization put together. The guru is interested only in the process of creating software and cares nothing about the output of said process. Consuming every minute of every meeting, the Process Guru likes to explain how "we're doing agile wrong" and pontificates about the need for more agile training. Usually, but not always, the Process Guru is recognizable by the Certified Scrum Master status. 

The "Jeopardy" Champion.
The expert on arcane trivia, this developer may or may not be generally productive, but stands as the one person on the team who always seems to possess some obscure bit of needed knowledge. Whether it's the details of how "volatile" works in Java, both before and after the changes to the memory model spec, or deep knowledge of tuning a JBoss AS 4.2.3 configuration, the "Jeopardy" Champion is a valuable asset (at least twice a year).

The Hipster Hacker from Hell. We really need to rewrite all of our software in Haskell because then our code will be beautiful. Never mind the costs! Did I say Haskell? Haskell was so last year. I mean Clojure because it will be simple! Bugs? Features? I have no time for such trivial matters. I have a whole new architecture to write in Ceylon!
The Architecture Astronaut. This developer loves complexity and never sees a problem too simple to deserve a multitier, distributed system using a Java application server, multiple message queues, SOAP-based Web services with distributed transactions, and native code in C++ for good measure. When not designing byzantine architectures, astronauts immerse themselves in the WS-* specs or CORBA manuals. They may be found associating with Hipster Hackers from Hell, scheming up a new distributed system built in a combination of Erlang, Scala + Akka, Node.js, and Haskell. The astronaut will try to spend at least half of the allocated time for the project drawing UML diagrams and "fleshing out the architecture." Mantra: "The project isn't done until it uses at least 7/8 of the patterns in the GoF book."
The Insecure Evangelist. This guy/gal designed the entire system, but is threatened by new suggestions from just about anybody. Basically, my ideas are good and yours are bad, unless I repackage them as my ideas.
The Code Poet. The poet's code is elegant and conforms beautifully to design patterns. On the other hand, the Code Poet holds you up in meetings forever and never notices the missed deadlines or the annoyed looks on other peoples' faces.
The Cloud Zealot. This character has never heard of (or doesn't believe in) the eight fallacies of distributed computing and couldn't spell "SLA" if you spotted him the "S," "L," and "A." However, they can leap on a trending buzzword like a lion stalking a gazelle on the savannah. The Cloud Zealot races to move everything "to the cloud" with no regard for security, latency, network outages, data interoperability, vendor lock-in, or the long-term viability of the SaaS vendor du jour. Secure in his knowledge that no fly-by-night SaaS offering has ever been hacked, leaking usernames, email addresses, and unencrypted passwords for every user account, the Cloud Zealot sleeps easy. Lucky for him, he'll have moved on to a new company before you discover that all of your employees identities are for sale by the Russian mafia.
The Traditionalist. "Why would you ever need anything other than Java and an Oracle DB?" "You should definitely run your application on WebSphere." "Oh, you want to send messages between nodes? Let me prepare the XML schema." 
The Uber Traditionalist. This party thinks Java is too newfangled and unproven for production use, preferring to develop on an AS/400, in RPG, using the SEU. The UT spends most of his time regaling you with tales of his youth, when the VAX was still a technological marvel and the PC was yet to be born. He probably built his first computer from raw transistors on a breadboard and never hesitates to remind the Hipster Hacker from Hell (his mortal enemy) that "the ideas in Node.js were originally developed in SNOBOL in the '70s, you know" or "Haskell is just a less pure and inferior LISP in many ways."
The Proprietary Priest. Telltale signs: Insists that all solutions should use proprietary tools from a trusted name; Perforce, Websphere, AIX, Oracle -- you get the idea. If Microsoft, IBM, or some other corporation didn't write it, then it must be crap.
If you recognized bits of yourself in the above, you may have enough introspection to avoid totally being one. If you don't think any of it applies to you, then almost certainly the people you work with know exactly which of the above you match.
Great software is never a solo endeavor. Figuring out that it isn't all about you is probably your first step.

Monday, April 22, 2013

Assigning objects to variables while exceptions thrown in ctor

Throwing Exceptions from Fields

In Java, when the constructor of an object that we are storing in a field throws an exception, we usually set it in our class' constructor. For example:
import java.io.*;
public class Foo implements AutoCloseable {
   private final ObjectInputStream in;
   public Foo() throws IOException {
     in = new ObjectInputStream(
       new BufferedInputStream(
         new FileInputStream("data.bin")));
   }
   public void close() throws IOException {
     in.close();
   }
   protected void finalize() throws Throwable {
     close();
     super.finalize();
   }
}
However, did you know that you could also construct the ObjectInputStream inside the field, as long as you had a constructor that threw the IOException? I knew this was possible, but to my shame I had not tried it out. Here is what you could do:

import java.io.*;
public class Foo implements AutoCloseable {
  private final ObjectInputStream in =
    new ObjectInputStream(
      new BufferedInputStream(
        new FileInputStream("data.bin")));
  public Foo() throws IOException {
  }
  public void close() throws IOException {
    in.close();
  }
  protected void finalize() throws Throwable {
    close();
    super.finalize();
  }
}

Thanks to Dr. Kabutz from his Crete Island hideaway: http://www.javaspecialists.eu/archive/Issue208.html

  

Wednesday, April 17, 2013

Software performance analogy

Notable code "You don't build a bridge, then try to add load-bearing capabilities at the end of the project -- but most software projects try to do exactly that"

Friday, April 5, 2013

Yellow train in NYC subway

Not often you can catch a glimpse of the maintenance train in the subway. These guys are used to do rail maintenance as well as collect garbage after midnight. This one looks to be from the sixties still operating


Tuesday, March 26, 2013

JavaScript in PHP

Printing a whole lot of JavaScript in PHP

.. granted you'd normally want to have a *.js file for your JS code but if you had to spew out a whole lot of JS code in PHP here is a easy way using lables and raw format :




function echoJavascript(){
        $jscode= <<<MY_JS
        <script type="text/javascript">
         blah blah blah... your javascript code here
        </script>
        MY_JS;
echo $jscode;
}




Monday, March 25, 2013

Bricked, Kicked, Picked, Hicked


  • you place it on the sidewalk with the screen side up. You drop a brick and if the screen cracks and the device no longer works, you have a bricked device.
  • If you get an iPad and cover it in bling, you have a tricked device.
  • If you stole it, you have a picked device and if you are a farmer, you have a hicked device.

Wednesday, March 13, 2013

The Joel Test


some good advice for your development team. It makes sense even if you are a one man team. you need to improvise on #12
  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing? 
Find explanation at    http://www.joelonsoftware.com/articles/fog0000000043.html

Wednesday, February 13, 2013

Quotes from World of Developers

Premature optimization is the source of all evil
-Donald Knuth
There are two ways of constructing a software design:
One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
-C.A.R. Hoare, The 1980 ACM Turing Award Lecture
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-Martin Fowler
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
-Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.
[Most managers] may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion
-Robert Martin (Uncle Bob), Clean code
The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time
-Tom Cargil Bell labs
Before software can be reusable it first has to be usable.
-Ralph Johnson
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
-Rick Osborne
The best way to predict the future is to implement it.
-Alan Key
Talk is cheap. Show me the code.
-Linus Torvalds
Perl – The only language that looks the same before and after RSA encryption.
-Keith Bostic
I invented the term ‘Object-Oriented’, and I can tell you I did not have C++ in mind.
-Alan Kay
Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.
-Linus Torvalds
Controlling complexity is the essence of computer programming.
-Brian Kernighan

Thursday, February 7, 2013

Sunset in downtown NYC

It's cold outside but this sunset over north cove just a few steps from World Trade Center is worth capturing.

Saturday, January 26, 2013

Spreading love on the bridge

After dropping off Kian at daycare.. I walked half way through the bridge before I noticed the flowery decorated bridge on this freezing morning.