RSS

Category Archives: future

MDD and DSL – I feel like I’m circling the drain

14 Sep

Have you ever seen one of those charity boxes that looks like a large funnel and when you put your coins in motion it goes round and round until it falls into the center hole only to be collected by the charity’s processor. Looks something like this. Well when I think about MDD (model driven development) and DSL (domain specific language) I feel like the coin going round and round.

MDD and DSL were and still are viable tools for deconstructing systems and processes that are to be implemented in hardware/software but to fail to recognize the history is pure folly. Many years ago they were referred to as DFD(Data Flow Diagram) and FFD(Funtion Flow Diagram). Sure, back in the day, we used analog systems to capture the details and now it’s digital but the results were exactly the same.  In fact even if you say that MDD is the new and improved DFD…. it’s new and improved in terms of same box of PopTarts with just a little less filling.

And so now I wrestle with OO.next(). Object Oriented programming was and continues to be leap years ahead of DFD/FFD and the jury would seem to be out on any comparisons to MDD/DSL. So instead let’s jump ahead another generation. What is the next version or incarnation of OO going to look like and is it ready for some early adoption now?

 
Leave a comment

Posted by on 2012/09/14 in architecture, future, Tools

 

Tags: , , ,

Linux Distros are Becoming More Like Windows…

25 Aug

It’s hard to admit but it’s happening and you can see it in the likes of Ubuntu 12.04 desktop (and earlier releases too) as well as Fedora 17. The first indicator was the need for advanced 3D video drivers in order to support the new desktop goodies. Sound like Aero/Glass yet?

This morning while I was updating a client’s Ubuntu 12.04 server was that there seemed to be a request to convert /etc/resolv.conf to /etc/resolveconf. This might seem like a subtle change but when you read the manpage for resolvconf you realize that your server is going to be running a few more daemons that you previously didn’t need. (I do not know enough about resolvconf and I’m certain the author would not be wasting our time but it feels wrong that we need a daemon where the traditional methods worked fine)

I watched a talk recently where the speaker pointed me to this doc. The interesting point is that the original Unix distro was only 10K lines of code. This speaks volumes considering the millions of LOC that are in the current distros. You did not get a GUI in 10K but it was a functioning OS. My complaint is that the dependency on current hardware and daemonizing everything that moves feels like a move away from the Linux roots.

PS: This will likely widen the splinter between the *nix and the BSD groups.

 
2 Comments

Posted by on 2012/08/25 in future

 

The secret sauce for effective scaling

19 Jul

Many people think that scaling is a matter of selecting one programming language over another. I do not think that anyone would argue that there are plenty of advantages in most proper functional languages like erlang over dynamic languages like python or ruby. What most developers fail to recognize is all software that needs to scale is actually a business with a profit motive. And most executives under emphasize “business” in their technology business.

Going back to the lessons of Henry Ford. Scaling production came from 2 key areas. (a) interchangeable parts. (b) the assembly line. While it was not particularly motivating for workers to be on the assembly line, in the same role, day after day. It paid the bills.

So which is cheaper? Cloning a machine or rewriting your application for some fractional gain? Even if rewriting your rewrite was to get 2 – 3 times performance increase, it’s simply not sustainable over time and the next rewrite. I wish there were a study on the cost per LOC(lines of code) for the different languages… my personal experience has been that demanding erlang coding will pay 2x the most demanding ruby. For any project there is a 1:1 ratio of LOC between erlang and ruby.

So the secret sauce:

  • know what your costs are and when you need your ROI to be
  • decide on a strategy and architecture that will scale to thousands of nodes; you do not have to implement this day one but you have to know where you are going.
  • Do not get wrapped up in the GIL, instead concentrate on IPC between processes on the same LAN and virtual WAN.
  • code to the roadmap and plan not to rewrite anything
  • segment responsibility into teams (tools, core, UI, etc)
  • always think about LTS from your providers. While you might not like Windows they are the kings of LTS these days. And if not them, at least there is Ubuntu and Red Hat
  • build tools tools tools
  • Don’t repeat yourself

Simply put, writing new code in order to scale to infinite levels suffers from the law of diminishing and delayed returns. Cloning hardware is a fixed and capitalizable expense with immediate returns.

 
Leave a comment

Posted by on 2012/07/19 in architecture, future

 

Tags:

The good and bad of the about.me SDK

10 Jul

The folks at AOL have done something interesting. They have created an SDK for their about.me property. I like my about.me page as an anchor to everything I’m doing or that I need and that I’m willing to make very public. But now that AOL has created an API/SDK some new mashups are bound to happen.

I question what is AOL’s endgame is here. about.me offers a metoo – email client of sorts and “offers” like coupons that you can never make go away. And yes you are giving them plenty of information and access to even more.

As for the good news. about.me’s API/SDK seems to be fairly new. That means that other than the stock services (read apps) there has not been much action. But now that anyone can add an app/service to about.me even the most humble app might get some traction.

As for the bad news. If there is a landrush I’m not certain what AOL will be able to do about it. Clearly if there is a vetting process then they can control the rate at which new services are added to the site. If the velocity or count gets too high they may have to make some drastic changes to the interface.

As I look at my about.me and the way that I use my browser and the internet I’m just not certain how or what I would add to this page. Of course a bitly link might be nice. So would a delicious look alike. But the fact of the matter is that about.me seems to be a metoo app itself. For example. I have an idea for an app that I would like to connect to about.me but I do not want to require that my users create about.me accounts in order to use my app. And I’m certain that I will not be able to attract other about.me users to install my app once the list grows.

Just plain confusing.

 
Leave a comment

Posted by on 2012/07/10 in future, social networking, Tools

 

Tags: ,

Why is middle management on the decline again?

27 Jun

I really hate this subject because it effects me directly. Back when Reagan was President we had a huge recession. As a result middle management was all but obliterated from the middle corporate America as management thought this was the way to survive. And we learned two important lessons from this reaction. (1) recession almost turned into depression and corporate America was almost erased (2) many middle managers spawned successful startup businesses. (the two are not offsetting even with the dot com boom and bust)

Now, it seems, that we are in economic hard times again and whether it’s a recession or depression is for future economists, however, I do know that middle management is being erased again; and top managers are calling it lean or agile. As a result the execs are making more money (as part of their “incentive” packages) and entry level positions have become highly competitive as the job market shrinks without rational stimulation. I wish that it was a fair competition but it’s not. It favors the young person. Not because they are smarter, faster, knowledgable, malleable, “agile” or even efficient but because they are cheaper. They do not have houses, cars, families, college tuition, electricity, water, heat or A/C. And of course retirement considerations.

Top-down total-agile-management might work in the EU where just about everything is socialized and retirement assured. But here in the US, where every 2 to 4 years we talk about how bankrupt the federal retirement system is, this obliteration of middle management and a genuine career path is paramount. Companies that do not support a middle management risk losing their knowledge base, fail to mentor or apprentice their line of succession, and are only interested in the short term benefits.

So my message to all senior and ‘C’ level executives. Start thinking about your company as if it were to exist for another 200 years and stop thinking about your own personal legacy. If you take care of the future then the future will take care of you.

 
4 Comments

Posted by on 2012/06/27 in business, future

 

My wishes for Apple and iOS

26 Jun

I have been thinking about the number of PCs that I have recycled and the number that need to be recycled. And then I think about my toddlers that could benefit from a computer but are clearly not ready for anything that looks like Windows or OSX. But what is amazing is that have just about mastered iOS. They can play games, recognize and switch games by their icons, view pictures and navigate the albums.

So here’s my wish. I want to recycle my old PCs by installing iOS on it so that my kids have something to play with. I just don’t see myself buying them a $750 iPad at the age of two and the iPad that I’m using is not ready to be recycled nor do I have more than one iPad that hand-me-downs are an option.

 
Leave a comment

Posted by on 2012/06/26 in architecture, future, home electronics

 

Tags:

Freelance IT / Programmer Consumerism

23 Jun

A few days ago I came across this article and as I ponder some of the projects I’m working on, clients and missed opportunities I’ve realized a few and important facts.

Every SOHO and small to medium business out there depends on computers and software just as much as they depend on electricity and the dial tone. So it’s a wonder to me why many of these businesses do not hire companies like DockYard. Not to implement some critical or non-critical application at $120 – $250/hr or $4,000 – $7,000/wk or more. But as a resource to make sure that the High School kid, summer intern, or college CS major does a good job or gets a solid background or framework to begin with.

I’m not trying to take jobs away from this cadre of would-be future Zucks; I’m trying to say that you, as a business owner depend on your systems and applications to keep your operating costs down and your productivity up. So when your systems are buggy, damaged, or down you’re losing money through failure to convert a customer, loss of a customer, or increased support costs. So it is your best interest to take that into consideration the next time you have to build and deploy a critical application based on the experience of a hello world level of experience.

PS: This editorial was paid for advertisement for the services of Florida Freelance IT LLC. I hope you’ll consider me for your next project.

 
Leave a comment

Posted by on 2012/06/23 in business, for hire, future

 

Fork bomb – Ruby

24 May

I’m reading a new book titled Working with Unix Processes which is published by, you guessed it, pragprog.com. I cannot tell if this book is golden or beta but that nugget aside it’s actually an easy book to read. The author is trying to show how connected Ruby is to Unix processes and for the most part he meets the mark.

What troubled me is not the tight coupling of Ruby to Unix but it was the notion of a fork bomb and that Ruby uses about 500MB (half a gig) of main memory before the application actually does anything. This suggests that with just a fews forks and average memory amounts one could bomb the target system.

Which has me asking the same question of Python, C, java and go.

PS: forking is probably not the right thing to do. daemontools and tools like it are a better approach for demonizing your apps.

 
6 Comments

Posted by on 2012/05/24 in architecture, future

 

Tags: , ,

Linux and *BSD need a lot of polish

04 May

Linux and *BSD need a lot of polish if they ever hope to assault the desktop. Chrome OS is supposed to be based on Linux but that’s the internals that people never see. The actual desktop is rendered from the Chrome browser and while this is akin to a dumb terminal it is still kludgy because it’s all running on top of X. And while X is powerful… it’s simply not modern enough to compete. (The same can be said for the various desktop managers). Frankly they all suck. The windows desktop is better than than an of the X/wm derivatives… even though Windows 7 seems to have chunky controls.

 
Leave a comment

Posted by on 2012/05/04 in Complaint Depatment, future, open source

 

Your Next Web Application Framework?

12 Apr

Suppose you are the person who has to make the decision as to what language and framework your startup is going to use to deploy it’s application.  What would you choose? There are so many interesting and qualified frameworks that are already powering a good portion of the internet.

(You don’t have to know the language and framework but enough to argue what makes it idea.)

What would it be?

For example: I read an article several years ago that strongly recommended Erlang. At the time it was a great idea. The author suggested that using Erlang would attract smart people and keep the actual number of respondents to something manageable. Since then I implemented several applications that in hindsight: (a) impossible to attract new talent. (b) the more time that passes the more fragile the app gets because my detail recollection is fading (c) and it lacks common tools that would make allow generalized apps to give access to “operators” instead of programmers.

Other examples include: perl, ruby, python… mojolicious, rails and sinatra, flask, tornadoweb, and django.

I have my ideas… what are yours?

 
Leave a comment

Posted by on 2012/04/12 in architecture, future, web

 

Tags: , , , , , , , , , , ,

← Older posts
 
One Page Docs

Creating a library one page at a time.

One Page Bugs

Reducing the friction of writing and fixing bugs or features.

Follow

Get every new post delivered to your Inbox.

Join 223 other followers