Generic
Thriving with Paradigm Shifts (or how not to become a dinosaur)
0Like most production systems, life happens in real time; and there has been several major paradigm shifts happening lately. It’s easy to shrug AJAX off as revamped XMLHTTP from late 90′s but we all know this isn’t exactly the case. With the thought process, frameworks and development around emerging technologies, sands are shifting faster than ever before.
For an outside viewer, changes are huge. What follows is not absolute technology-counterpart-comparison but rather area under the drift. Traditional RDBMS to NoSQL, traditional Web Servers to Node and nginx, from typesafe languages to dynamic typing, tradional MVC (spring/asp.net) to full stack scaffoldings (RoR), HTTP/SOAP to REST/JSON, postbacks to async, scaling up to Hadoop, ACID to CAP, proprietary data centers to cloud and the list goes on. Again, this list is not necessarily an absolute comparison of technology counterparts but these analogies have definitely come a long way since Tim O’Reilly did his famous what is web 2.0 definition and table (see below) in 2005.
| Web 1.0 | Web 2.0 | |
|---|---|---|
| DoubleClick | –> | Google AdSense |
| Ofoto | –> | Flickr |
| Akamai | –> | BitTorrent |
| mp3.com | –> | Napster |
| Britannica Online | –> | Wikipedia |
| personal websites | –> | blogging |
| evite | –> | upcoming.org and EVDB |
| domain name speculation | –> | search engine optimization |
| page views | –> | cost per click |
| screen scraping | –> | web services |
| publishing | –> | participation |
| content management systems | –> | wikis |
| directories (taxonomy) | –> | tagging (“folksonomy”) |
| stickiness | –> | syndication |
For computer scientists and software engineers with sound foundation in algorithms, operating systems, database systems (including distributed databases), computer networking and enterprise architecture, the situation isn’t quite hostile. There is no need to feel threatened by falling behind the learning curve due to lack of fundamental understanding and aptitude. However one should definitely be concerned if it’s due to, in Seth Godin’s terms, lizard brain laziness in learning and prototyping about these up and coming changes.
The fundamentals of distributed databases hasn’t changed much; however the ever-networked nature of world wide web has made it more plausible then ever to use them in practice. To draw an analogy from OSI model, majority of delta is happening in the application layer. This learning curve can only be overcome through training activities learning and persistent efforts. The same way we have avoided architectural astronauts and anti-patterns by writing code and optimizing it to solve real business and technology problems, it would be bridged by coding up mapreduce or improve technical vocabulary while idling through yet another View Model implementation. At least that’s how I envision it.
“Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road.”-Stewart Brand
How to tweet (or blog) in Urdu
Gone are the days of inpage; now writing Urdu universally in unicode is rather easy on both mac and PC (and Linux). Yesterday I was asked by a friend regarding how to tweet in Urdu. Here is a short 3 step guide without reinventing the wheel.
1. If you are not familiar with Urdu phonetic keyboard, the quickest way is to use Google Transliterate http://www.google.com/transliterate/Urdu
2. Urdu keyboard is quite easy to learn. If you want native support of Urdu in your operating system, follow the steps according to your OS.
Since I use both MAC and PC for native urdu support, I have tried and tested both the mechanisms and they work just fine.
3. If you are using transliteration, you would copy and paste the Urdu text into your favorite twitter / blogging client. Not all clients support unicode; tweetdeck didn’t use to but twitter.com does support Unicode.
Happy tweeting / blogging.
Project Euler
I recently have joined Project Euler, introduced through a friend an co-worker Linh Vu. A simpler, more mathematics oriented top coder (for the TC fans out there), Project Euler is defined as ”a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve.” The problems increase in the level of complexity starting from simpler ones like “Add all the natural numbers below one thousand that are multiples of 3 or 5.” to building bozo sort or a A Kempner-like series. The site keeps track of your progress and you can make friends on the site, via a guid like key. Yes, that’s social networking the nerd way. Here is my key “friend key”. 49113135298912_6fda96436085285581e71ee6fb83e3c9
Try it out. http://projecteuler.net/
Making a Business Case for MVC
ASP.NET MVC is the Microsoft implementation of Model View Controller design pattern for their web platform. It provides a clean separation of concerns, promotes decoupling between code and UI and supports test driven development practices which are hard to follow in a UI driven environment such as web forms. Developers often find themselves in the position of justifying why using or upgrading to a modern web framework like ASP.NET MVC is a good business decision. There are various advantages to using the MVC framework including but not limited to ease of maintenance, enhanced security, improved performance and scalability. Following are few salient features with brief description to addresses the ROI part of adapting MVC. Based on my experience of migrating a large scale website from ASP.NET to ASP.NET MVC framework, it gives developers a powerful, pattern-compliant way of building dynamic websites which enables a ‘clean separation of concerns’ and gives full control over markup for agile development.
- Facilitates Modern Web Experience: ASP.NET MVC framework provides the facility to create intuitive search engine friendly URL for better conversion. It supports out of the box integration with modern JavaScript/AJAX engines such as JQuery which helps creating a responsive, interactive and overall better UI/UX experience.
- Quicker Turn Around for Enhancement Requests: Business loves it and by a cleaner separation of code and contents, a web team can entertain the request of content changes in a much faster manner. This include copy changes, image swaps, multivariate testing, ad-tracking pixels and affiliate marketing. As part of your organization’s Content Management System (CMS) strategy, you can have content managers modify the “views” effectively enabling them to make marketing verbiage and page layout changes without touching code. This is usually a challenging task in a UI-code coupled environment such as ASP.NET webforms.
- Enhanced Security: Using the built in features supported in .NET 4.0, ASP.NET MVC provides security against malicious cross site request forgery and scripting attacks using specialized encoding and Anti-Forgery Request tokens. Information and web application security teams promotes these features to be used as standard web development practices.
- Performance & Scalability: Yes, no more viewstate! With lighter HTML markup and cleaner separation of concerns, ASP.NET MVC decreases the page load time, promotes load balancer based caching and inherently follows the design of stateless nature of web. Microsoft has provided no official comparison statistics but developer community and professional working experience with MVC shows that MVC is much faster than classic ASP.NET.
- Compliance: MVC provides very high degree of control over markup emitted to the client browser therefore ADA Compliance and other web standards (XHTML, HTML 5 etc) are much easier to adapt.
- Test Driven Development: As a web framework following MVC design pattern, ASP.NET MVC promotes the usage of test driven development; a technique which has proven to reduce the number of bugs early on and helps in regression testing. Therefore, it effectively reduces development, QA and regression testing time for most changes with the help of automated unit tests. The framework also decouples the components which a single webpage may use, making it possible to test individual components in isolation.
- Reusability: With isolation of views, we can now leverage the existing applications to build new websites. For example, developers can work on new “views” that are specific for the mobile browser experience without developing an entirely new web application. This eliminates code duplication which would be hard to achieve with ASP.NET webforms.
References
Aspect.NET 2.2 Released
Version 2.2 of Aspect.NET – aspect-oriented programming toolkit for the .NET platform, integrated to Visual Studio has been released. Aspect.NET is developed at St. Petersburg University under the supervision of Professor Vladimir O. Safonov. The new feature of Aspect.NET 2.2 is in support of the second language – Visual Basic (alongside with C#) as aspect implementation language.
Multi-language AOP with Aspect.NET is an enhancement of multi-language programming with .NET. In .NET, it is possible to develop different modules (classes) of an application in different, more suitable languages and integrate them into a single .NET application. In Aspect.NET, it is now possible to implement aspects either in C# or in VB, whatever language might be the most appropriate for the aspect’s functionality, and to weave aspects to target applications written in C# or VB.
Further details can also be found on the project’s website.
The cost of inaction
Seth Godin blogged couple of days ago titled “Failure, success and neither”
It was so well said that I am compelled to quote it hear with all due credits.
The math is magical: you can pile up lots of failures and still keep rolling, but you only need one juicy success to build a career.
The killer is the category called ‘neither’. If you spend your days avoiding failure by doing not much worth criticizing, you’ll never have a shot at success. Avoiding the thing that’s easy to survive keeps you from encountering the very thing you’re after.
And yet we market and work and connect and create as if just one failure might be the end of us.
Beautiful!
This is also very true for the cost of inaction in Entrepreneurship.
Migration Woes
Hello World. I am migrating my blog over; stay tuned and I apologize for the inconvenience.
[Update]
The blog migration has completed. Thanks to the wordpress import module by Rob Walling, Aaron Lerch and Kavinda Munasinghe and the dasblog spam/trackback scrubbing tool by Richard Hundhausen.
For the BlogML to WordPress import module. you would need to drop these files into the WordPress Imports directory (/wp-admin/import/). Details of the process are on Kavinda’s blog.
I was almost going to write a utility to parse the /contents folder and make calls to WP using the Joe’s Blogs library (codeplex project) but glad it didn’t come to that.
http://www.alexjamesbrown.com/geek/development/dotnet/using-joeblogs/
Jan 20th – Windows Server AppFabric and “Velocity” w/ Jon Flanders
Update: This meeting was canceled due to weather conditions in Monrovia. This is now rescheduled to Wed 17th Feb.
Tomorrow Jan 20th, our user group will be hosting an evening with Jon Flanders who will be speaking about Windows Server AppFabric and Velocity Project. He is an amazing speaker and a developer extraordinaire so if you live in the San Gabriel Valley Area, please swing by to the meeting. The event is free to attend and pizza is provided. Here is a brief abstract for the talk.
Abstract:
Windows Server AppFabric is a set of integrated technologies that make
it easier to build, scale and manage Web and composite applications
that run on IIS. For Web applications, AppFabric provides caching
capabilities to provide high-speed access, scale, and high availability
to application data. This feature was previously codenamed “Velocity”.
“Velocity” is a distributed in-memory cache that provides applications
with high-speed access, scale, and high availability to application
data. Client applications that utilize the cache may be distributed
across multiple computers or processes. Jon will be exploring the
feature of Velcoity in detail.
For further details please visit the user group website.
97 Things Every Software Architect Should Know
During my recent Borders’s-browsing, I came across Richard
Monson-Haefel’s book, 97
Things Every Software Architect Should Know with the tag line, “Collective
Wisdom from the Experts”. The book is interesting and even though it falls
short in providing details, gives a good overview of architectural principles. Mind
you, this is not a book with case studies or principles of how to define an
effective interface with example but more of a 10K ft view of software
architectural “principles”. Recently I have seen few books which belong to this
genre of collective wisdom aka geek interviews such as “Secrets
of the Rock Star Programmers: Riding the IT Crest” and “Coders
at work”. I think 97 things is a good addition to this observe-and-report
tradition from people presumably working in the trenches of software
development.
Following is the table of contents and I have highlighted
the chapters/metaphors I liked.
1. Don’t Put Your Resume Ahead of
the Requirements
2. Simplify Essential
Complexity; Diminish Accidental Complexity
3. Chances Are, Your Biggest
Problem Isn’t Technical
4. Communication Is King;
Clarity and Leadership, Its Humble Servants
5. Application Architecture
Determines Application Performance
6. Seek the Value in Requested
Capabilities
7. Stand Up!
8. Everything Will Ultimately
Fail
9. You’re Negotiating More Often
Than You Think
10. Quantify
11. One Line of Working Code Is
Worth 500 of Specification
12. There Is No
One-Size-Fits-All Solution
13. It’s Never Too Early to
Think About Performance
14. Architecting Is About
Balancing
15. Commit-and-Run Is a Crime
16. There Can Be More Than One
17. Business Drives
18. Simplicity Before Generality,
Use Before Reuse
19. Architects Must Be Hands On
20. Continuously Integrate
21. Avoid Scheduling Failures
22. Architectural Tradeoffs
23. Database As a Fortress
24. Use Uncertainty As a Driver
25. Warning: Problems in Mirror
May Be Larger Than They Appear
26. Reuse Is About People and
Education, Not Just Architecture
27. There Is No ‘I’ in
Architecture
28. Get the 1,000-Foot View
29. Try Before Choosing
30. Understand the Business Domain
31. Programming Is an Act of
Design
32. Give Developers Autonomy
33. Time Changes Everything
34. “Software Architect”
Has Only Lowercase a’s; Deal with It
35. Scope Is the Enemy of
Success
36. Value Stewardship Over
Showmanship
37. Software Architecture Has
Ethical Consequences
38. Skyscrapers Aren’t Scalable
39. Heterogeneity Wins
40. It’s All About Performance
41. Engineer in the White Spaces
42. Talk the Talk
43. Context Is King
44. Dwarves, Elves, Wizards, and
Kings
45. Learn from Architects of
Buildings
46. Fight Repetition
47. Welcome to the Real World
48. Don’t Control, but Observe
49. Janus the Architect
50. Architects’ Focus Is on the
Boundaries and Interfaces
51. Empower Developers
52. Record Your Rationale
53. Challenge
Assumptions—Especially Your Own
54. Share Your Knowledge and
Experiences
55. Pattern Pathology
56. Don’t Stretch the Architecture
Metaphors
57. Focus on Application
Support and Maintenance
58. Prepare to Pick Two
59. Prefer Principles, Axioms,
and Analogies to Opinion and Taste
60. Start with a Walking Skeleton
61. It Is All About The Data
62. Make Sure the Simple Stuff Is
Simple
63. Before Anything, an
Architect Is a Developer
64. The ROI Variable
65. Your System Is Legacy; Design
for It
66. If There Is Only One
Solution, Get a Second Opinion
67. Understand the Impact of
Change
68. You Have to Understand
Hardware, Too
69. Shortcuts Now Are Paid Back
with Interest Later
70. “Perfect” Is the
Enemy of “Good Enough”
71. Avoid “Good Ideas”
72. Great Content Creates Great
Systems
73. The Business Versus the Angry
Architect
74. Stretch Key Dimensions to
See What Breaks
75. If You Design It, You
Should Be Able to Code It
76. A Rose by Any Other Name Will
End Up As a Cabbage
77. Stable Problems Get
High-Quality Solutions
78. It Takes Diligence
79. Take Responsibility for
Your Decisions
80. Don’t Be Clever
81. Choose Your Weapons Carefully,
Relinquish Them Reluctantly
82. Your Customer Is Not Your
Customer
83. It Will Never Look Like That
84. Choose Frameworks That Play
Well with Others
85. Make a Strong Business Case
86. Control the Data, Not Just the
Code
87. Pay Down Your Technical
Debt
88. Don’t Be a Problem Solver
89. Build Systems to Be Zuhanden
90. Find and Retain Passionate
Problem Solvers
91. Software Doesn’t Really Exist
92. Learn a New Language
93. You Can’t Future-Proof
Solutions
94. The User Acceptance Problem
95. The Importance of Consommé
96. For the End User, the
Interface Is the System
97. Great Software Is Not Built,
It Is Grown