Memorandums, Logbook & Shares: February 2015

Thursday, February 26, 2015

Protect from DDos - Cloud mitigation provider

http://www.networkworld.com/article/2170051/tech-primers/tech-primers-four-ways-to-defend-against-ddos-attacks.html
http://ddos-protection-services-review.toptenreviews.com/
http://www.incapsula.com/ddos-protection-for-aws.html
https://blog.destiny.gg/protection-from-ddos-attacks/
http://www.incapsula.com/ddos-protection-for-aws.html

Wednesday, February 25, 2015

97 things that every system architect should know

Don't put your resume ahead of the requirements by Nitin Borwankar
Simplify essential complexity; diminish accidental complexity by Neal Ford
Chances are your biggest problem isn't technical by Mark Ramm
Communication is King; Clarity and Leadership its humble servants by
Mark Richards
Architecting is about balancing by Randy Stafford
Seek the value in requested capabilities by Einar Landre
Stand Up! by Udi Dahan
Skyscrapers aren't scalable by Micheal Nygard
You're negotiating more often than you think. by Michael Nygard
Quantify by Keith Braithwaite
One line of working code is worth 500 of specification by Allison Randal
There is no one-size-fits-all solution by Randy Stafford
It's never too early to think about performance by Rebecca Parsons
Application architecture determines application performance by Randy
Stafford
Commit-and-run is a crime. by Niclas Nilsson
There Can be More than One by Keith Braithwaite
Business Drives by Dave Muirhead
Simplicity before generality, use before reuse by Kevlin Henney
Architects must be hands on by John Davies
Continuously Integrate by Dave Bartlett
Avoid Scheduling Failures by Norman Carnovale
Architectural Tradeoffs by Mark Richards
Database as a Fortress by Dan Chak
Use uncertainty as a driver by Kevlin Henney
Scope is the enemy of success by Dave Quick
Reuse is about people and education, not just architecture by Jeremy Meyer
There is no 'I' in architecture by Dave Quick
Get the 1000ft view by Erik Doernenburg
Try before choosing by Erik Doernenburg
Understand The Business Domain by Mark Richards
Programming is an act of design by Einar Landre
Time changes everything by Philip Nelson
Give developers autonomy by Philip Nelson
Value stewardship over showmanship by Barry Hawkins
Warning, problems in mirror may be larger than they appear by Dave Quick
The title of software architect has only lower-case 'a's; deal with it
by Barry Hawkins
Software architecture has ethical consequences by Michael Nygard
Everything will ultimately fail by Michael Nygard
Context is King by Edward Garson
It's all about performance by Craig L Russell
Engineer in the white spaces by Michael Nygard
Talk the Talk by Mark Richards
Heterogeneity Wins by Edward Garson
Dwarves, Elves, Wizards, and Kings by Evan Cofsky
Learn from Architects of Buildings by Keith Braithwaite
Fight repetition by Niclas Nilsson
Welcome to the Real World by Gregor Hohpe
Don't Control, but Observe by Gregor Hohpe
Janus the Architect by Dave Bartlett
Architects focus is on the boundaries and interfaces by Einar Landre
Challenge assumptions - especially your own by Timothy High
Record your rationale by Timothy High
Empower developers by Timothy High
It is all about the data by Paul W. Homer
Control the data, not just the code by Chad LaVigne
Don't Stretch The Architecture Metaphors by David Ing
Focus on Application Support and Maintenance by Mncedisi Kasper
Prepare to pick two by Bill de hOra
Prefer principles, axioms and analogies to opinion and taste by Michael
Harmer
Start with a Walking Skeleton by Clint Shank
Share your knowledge and experiencesby Paul W. Homer
Make sure the simple stuff is simple by Chad LaVigne
If you design it, you should be able to code it. by Mike Brown
The ROI variable by George Malamidis
Your system is legacy, design for it. by Dave Anderson
If there is only one solution, get a second opinion by Timothy High
Understand the impact of change by Doug Crawford
You have to understand Hardware too by Kamal Wickramanayake
Shortcuts now are paid back with interest later by Scot Mcphee
"Perfect" is the Enemy of "Good Enough" by Greg Nyberg
Avoid "Good Ideas" by Greg Nyberg
Great content creates great systems by Zubin Wadia
The Business Vs. The Angry Architect by Chad LaVigne
Stretch key dimensions to see what breaks by Stephen Jones
Before anything, an architect is a developer by Mike Brown
A rose by any other name will end up as a cabbage by Sam Gardiner
Stable problems get high quality solutions by Sam Gardiner
It Takes Diligence by Brian Hart
Take responsibility for your decisions by Yi Zhou
Don't Be a Problem Solver by Eben Hewitt
Choose your weapons carefully, relinquish them reluctantly by Chad LaVigne
Your Customer is Not Your Customer by Eben Hewitt
It will never look like that by Peter Gillard-Moss
Choose Frameworks that play well with others by Eric Hawthorne
Make a strong business case by Yi Zhou
Pattern Pathology by Chad LaVigne
Learn a new language by Burk Hufnagel
Don't Be Clever by Eben Hewitt
Build Systems to be Zuhanden by Keith Braithwaite
Find and retain passionate problem solvers by Chad LaVigne
Software doesn't really exist by Chad LaVigne
Pay down your technical debt by Burk Hufnagel
You can't future-proof solutions by Richard Monson-Haefel
The User Acceptance Problem by Norman Carnovale
The Importance of Consommé by Eben Hewitt
For the end-user, the interface is the system by Vinayak Hegde
Great software is not built, it is grown by Bill de hora

97 things that a programmer should know

Act with Prudence
Apply Functional Programming Principles
Ask "What Would the User Do?" (You Are Not the User)
Automate Your Coding Standard
Beauty Is in Simplicity
Before You Refactor
Beware the Share
The Boy Scout Rule
Check Your Code First Before Looking to Blame Others
Choose Your Tools with Care
Code in the Language of the Domain
Code Is Design
Code Layout Matters
Code Reviews
Coding with Reason
A Comment on Comments
Comment Only What the Code Cannot Say
Continuous Learning
Convenience Is Not an –ility
Deploy Early and Often
Distinguish Business Exceptions from Technical
Do Lots of Deliberate Practice
Domain-Specific Languages
Don't Be Afraid to Break Things
Don't Be Cute with Your Test Data
Don't Ignore That Error!
Don't Just Learn the Language, Understand its Culture
Don't Nail Your Program into the Upright Position
Don't Rely on "Magic Happens Here"
Don't Repeat Yourself
Don't Touch That Code!
Encapsulate Behavior, Not Just State
Floating-Point Numbers Aren't Real
Fulfill Your Ambitions with Open Source
The Golden Rule of API Design
The Guru Myth
Hard Work Does Not Pay Off
How to Use a Bug Tracker
Improve Code by Removing It
Install Me
Inter-Process Communication Affects Application Response Time
Keep the Build Clean
Know How to Use Command-line Tools
Know Well More than Two Programming Languages
Know Your IDE
Know Your Limits
Know Your Next Commit
Large Interconnected Data Belongs to a Database
Learn Foreign Languages
Learn to Estimate
Learn to Say "Hello, World"
Let Your Project Speak for Itself
The Linker Is Not a Magical Program
The Longevity of Interim Solutions
Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly
Make the Invisible More Visible
Message Passing Leads to Better Scalability in Parallel Systems
A Message to the Future
Missing Opportunities for Polymorphism
News of the Weird: Testers Are Your Friends
One Binary
Only the Code Tells the Truth
Own (and Refactor) the Build
Pair Program and Feel the Flow
Prefer Domain-Specific Types to Primitive Types
Prevent Errors
The Professional Programmer
Put Everything Under Version Control
Put the Mouse Down and Step Away from the Keyboard
Read Code
Read the Humanities
Reinvent the Wheel Often
Resist the Temptation of the Singleton Pattern
The Road to Performance Is Littered with Dirty Code Bombs
Simplicity Comes from Reduction
The Single Responsibility Principle
Start from Yes
Step Back and Automate, Automate, Automate
Take Advantage of Code Analysis Tools
Test for Required Behavior, Not Incidental Behavior
Test Precisely and Concretely
Test While You Sleep (and over Weekends)
Testing Is the Engineering Rigor of Software Development
Thinking in States
Two Heads Are Often Better than One
Two Wrongs Can Make a Right (and Are Difficult to Fix)
Ubuntu Coding for Your Friends
The Unix Tools Are Your Friends
Use the Right Algorithm and Data Structure
Verbose Logging Will Disturb Your Sleep
WET Dilutes Performance Bottlenecks
When Programmers and Testers Collaborate
Write Code as If You Had to Support It for the Rest of Your Life
Write Small Functions Using Examples
Write Tests for People
You Gotta Care About the Code
Your Customers Do Not Mean What They Say

Tuesday, February 24, 2015

Comparing Paas - Heroku, Engine Yard, Digital Ocean, ...

https://www.airpair.com/ruby-on-rails/posts/rails-host-comparison-aws-digitalocean-heroku-engineyard
https://ninefold.com/performance/
http://www.scriptrock.com/articles/heroku-appengine

Monday, February 23, 2015

Topics on AWS DDos

http://www.infoworld.com/article/2608076/data-center/murder-in-the-amazon-cloud.html
http://www.ithome.com.tw/news/88797
http://www.reviewmylife.co.uk/blog/2011/05/19/amazon-cloudfront-and-s3-maximum-cost/
http://www.behind-the-enemy-lines.com/2012/04/google-attack-how-i-self-attacked.html
http://www.networkcomputing.com/cloud-infrastructure/code-spaces-a-lesson-in-cloud-backup/a/d-id/1279116
http://www.infoworld.com/article/2608076/data-center/murder-in-the-amazon-cloud.html

Backup administrator rule 3-2-1

Backup administrator's rule of 3-2-1, which requires three copies of any piece of data, on two different media with one offsite.

Sunday, February 22, 2015

Revisit the basics: Encapsulation

Encapsulation is the techinque of making fields in a class private and
providing access to the fields via public methods.
Benefits:
1. Read/Write access control.
2. Able to change the data processing of a field without changing user's
code.

Practice - High cohesion, Low coupling

High cohesion: A class has a clear responsibility and all of the implementation of that responsibility is close together or in one place. For example, to put all the logic to write to database in one class or several classes in a module, instead of letting every part of the application that needs to write to database implement that logic in its own class.

Low coupling: A module or class to be decoupled if it does not have many dependencies on other classes or modules. It reduces the impact of a change in one module across other modules. Loosely coupled software is easier to reuse because it doesn't have many other dependencies to be included.

Thursday, February 12, 2015

Tip of the day: Scale up first, then scale out

... Jacques makes the point we often make on this site: scale up first, then scale out. If a machine with 64 cores and 256G of RAM no longer works for you, then scale out. Start small and evolve....

http://highscalability.com/blog/2015/2/11/rescuing-an-outsourced-project-from-collapse-8-problems-foun.html

Wednesday, February 11, 2015

Why node.js 2

Reference: http://www.javaworld.com/article/2104480/java-web-development/why-use-node-js.html

In one sentence: Node.js shines in real-time web applications employing push technology over websockets. What is so revolutionary about that? Well, after over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections, where both the client and server can initiate communication, allowing them to exchange data freely. This is in stark contrast to the typical web response paradigm, where the client always initiates communication. Additionally, it's all based on the open web stack (HTML, CSS and JS) running over the standard port 80.

Still, Node.js is no silver bullet; in fact it has some real weaknesses -- for instance in CPU-intensive operations and other heavy computation. Find out why Node.js is becoming a go-to platform for some kinds of web development, and why in some cases you still might want to choose another option, like Java.

Why note.js 1

Some says:

Reference: http://blog.modulus.io/top-10-reasons-to-use-node

TOP 10 REASONS TO USE NODE.JS
modulesnpmnode.jsTop 10 Reasons To Use Node.js
There are many great reasons to use Node.js, regardless of experience level. Take a look into what some of the greatest practical reasons are to use Node and why you should love it.

I get it. You're not a bandwagon developer. You don't use the cool, trendy platform just because everyone else is. That's why you haven't looked seriously at Node.js yet. (Or your boss hasn't let you yet.) Well, it's time to look again. There are many great, practical reasons to use Node. Here are ten of them.

1. You Already Know JavaScript
Let me guess. You're using a rich client framework (Angular, Ember, Backbone) and a REST-ful server-side API that shuttles JSON back and forth. Even if you're not using one of those frameworks, you've written your own in jQuery. So if you're not using Node.js on the server, then you're constantly translating. You're translating two things: 1) the logic in your head from JavaScript to your server-side framework, and 2) the HTTP data from JSON to your server-side objects.

By using JavaScript throughout your app, you not only gain mental energy, you gain practicality as well. By potentially re-using your models, and templates, you reduce the size of your application which reduces complexity and chance for bugs.

JavaScript as a language is eating the world. It is not going away soon. There is a JavaScript runtime on every personal computer in the world, and it looks to stay that way for awhile.

2. It's Fast
Node.js is a JavaScript runtime that uses the V8 engine developed by Google for use in Chrome. V8 compiles and executes JavaScript at lightning speeds mainly due to the fact that V8 compiles JavaScript into native machine code.

In addition to lightning fast JavaScript execution, the real magic behind Node.js is the event loop. The event loop is a single thread that performs all I/O operations asynchronously. Traditionally, I/O operations either run synchronously (blocking) or asynchronously by spawning off parallel threads to perform the work. This old approach consumes a lot of memory and is notoriously difficult to program. In contrast, when a Node application needs to perform an I/O operation, it sends an asynchronous task to the event loop, along with a callback function, and then continues to execute the rest of its program. When the async operation completes, the event loop returns to the task to execute its callback.

In other words, reading and writing to network connections, reading/writing to the filesystem, and reading/writing to the database–all very common tasks in web apps–execute very, very fast in Node. Node allows you to build fast, scalable network applications capable of handling a huge number of simultaneous connections with high throughput.

3. Tooling

npm is the Node.js package manager and it... is... excellent. It does, of course, resemble package managers from other ecosystems, but npm is fast, robust, and consistent. It does a great job at specifying and installing project dependencies. It keeps packages isolated from other projects, avoiding version conflicts. But it also handles global installs of shell commands and platform-dependent binaries. I can't remember a time with npm where I've had to ask myself, "Why are those modules conflicting? Where is that module installed? Why is it picking up this version and not that one?"

grunt is the venerable task runner, but new kids on the block gulp, brunch, and broccoli focus on builds that transform your files, and take advantage of JavaScript's strong file streams capabilities.

4. You Already Know JavaScript, Again

So you've decided to use JavaScript on the server, and you're proud of your decision that avoids all that translating from client data to server data. But persisting that data to the database requires even more translations!

There's good news. If you're using an object database like Mongo, then you can extend JavaScript to the persistence layer as well.

Using Node.js allows you to use the same language on the client, on the server, and in the database. You can keep your data in its native JSON format from browser to disk.

5. Real-time Made Easy
If Node.js excels at many concurrent connections, then it makes sense that it excels at multi-user, real-time web applications like chat and games. Node's event loop takes care of the multi-user requirement. The real-time power comes thru use of the websocket protocol. Websockets are simply two-way communications channels between the client and server. So the server can push data to the client just as easily as the client can. Websockets run over TCP, avoiding the overhead of HTTP.

Socket.io is one of the most popular websocket libraries in use, and makes collaborative web applications dead simple. Here's a simple server using socket.io:

var app = require('http').createServer(handler)
var io = require('socket.io')(app);

app.listen(8080);

io.on('connection', function (socket) {

// Send a message to the client
socket.emit('event to client', { hello: 'world' });

// Handle a message from the client
socket.on('event from client, function (data) {
    console.log(data);
});
});
6. Streaming data
Traditionally, web frameworks treat HTTP requests and responses as whole data objects. In fact, they're actually I/O streams, as you might get if you streamed a file from the filesystem. Since Node.js is very good at handling I/O, we can take advantage and build some cool things. For example, it's possible to transcode audio or video files while they're uploading, cutting down on the overall processing time.

Node can read/write streams to websockets just as well as it can read/write streams to HTTP. For example, we can pipe stdout from a running process on the server to a browser over a websocket, and have the webpage display the output in real-time.

7. One Codebase And Your Real-time For Free
If you've made it this far, you may ask yourself, "If Node.js allows me to write JavaScript on the client and server, and makes it easy to send data between the client and server, can I write a web app that runs a single codebase on both client and server, and automatically synchronizes data between the two?"

The answer to your question would be yes, and the framework for that app would be Meteor. Meteor is a next-generation web framework built atop Node. It runs the same codebase on the both the client and server. This allows you to write client code that saves directly to a database. Then, that data is automatically persisted to the server. It works the other way too! Any data changes on the server are automatically sent to the client. It gets better. Any webpage displaying that data reacts automatically and updates itself!

// Save the value of 'name' upon clicking 'submit' directly in the browser!
'.click .submit': function(e, tpl) {
Users.update(
    { _id: this._id },
    { $set: { name: $('.name').val() }}
);
}
8. Corporate Caretaker
The inherent risk with any open-source project is abandonment by its volunteer maintainers. This isn't the case with Node.js. Node is currently sponsored by Joyent, who has hired a project lead and other core contributors, so there is a real company backing the future of the project. Not to mention there are a great number of major companies backing the project at every level including Walmart, Microsoft, Yahoo, Paypal, Voxer, and more.

9. Hosting

With rapid adoption, world-class Node.js hosting is also proliferating. In particular, Platform-as-a-Service (PaaS) providers such as Modulus and other reduce deployments to a single command. Even the granddaddy of PaaS, Heroku, now formally supports Node deployments.

10. Every Developer Knows (A Little) JavaScript
This one's for your boss.

Since the dawn of the web, there have been JavaScript onclick's and onmouseover's. Every web developer has coded a little JavaScript, even if that JavaScript was hacking a jQuery plugin. Finding web development talent is terribly difficult these days. So when choosing a web platform, why not choose the platform whose language is known by every web developer in the world?

In Conclusion, A Bonus!
But wait, there's more! As with any platform or product, open-source or otherwise, its community is a huge influencing factor. And Node's is second to none. From meetups to conferences, there are really smart people working on the ecosystem every day. At the same time, the community is welcoming. These same smart people are always willing to offer help to folks new to Node, or even programming in general. You won't feel bad for asking a question on IRC or opening an issue. This community is also very active, with over 91,000 modules on npm. And this community is generous. In 2013, individuals donated over $70,000 to help run the public npm servers.

Yes, Node is trendy at the moment. This is web development, so next week Node may be dead, and the next hot thing will have arrived (will it be Go or Elixir?). But give it a try.

Monday, February 2, 2015

Toolbox - front end framework: Bootstrap & Foundation

http://getbootstrap.com/2.3.2/index.html
http://foundation.zurb.com/