Hacker News Reader

Comment by moocow01 | Hacker News Reader

I myself have reverted back to doing "everything" myself... I don't use frameworks besides my own crap.

The downfalls... 1) stuff can take a LOT longer to develop, 2) sometimes I feel like I'm stuck implementing middleware when I should be developing features, 3) there is more room for bugs to sneak in 4) scaling could be tougher when/if the need arises

The positive... 1) I for once feel like I actually know the full flow of execution and this at times makes certain solutions much easier 2) I don't feel that Im on the treadmill of hopping from learning one framework to the other 3) it grows my skill 4) I feel more like Im chiseling something from one stone rather than tying together rocks

Im not entirely sure Id recommend what Im doing - in someways its really stupid but I personally get gratification from it and oddly feel more productive than when Im fusing together multiple frameworks.

View on HN

> ... in programming there is a wide-spread 1st order theory that one shouldn't build one's own tools, languages, and especially operating systems. This is true—an incredible amount of time and energy has gone down these ratholes. On the 2nd hand, if you can build your own tools, languages and operating systems, then you absolutely should because the leverage that can be obtained (and often the time not wasted in trying to fix other people's not quite right tools) can be incredible.

Alan Kay, "The Power Of The Context", p.8, https://docs.google.com/viewer?url=http://www.vpri.org/pdf/m...

EDIT google search (mostly) provides a "Quick View" link for pdfs - there's also addons for chrome/FF that add a right-click context menu option to open a file in google view, useful for checking out lecture notes/slides, that often are a list of pdf links.

thank you for posting a google doc view link!

A good middle ground is using a collection of well written libraries that achieve the function you're looking or. Doing that instead of using a monolithic framework has some nice benefits:

1) The libraries are guaranteed to be decoupled.

2) The libraries are better maintained individually.

3) It's much easier (sometimes painless) to replace them if they don't suit your needs.

4) ... probably many more.

The hardest part of bootstrapping a new application is the boilerplate. Let someone else take care of managing session state, generating SQL queries, URL routing, DI containers, buffered logging, templating, etc. If you haven't found something that suits your needs, sure, write it yourself.

I wouldn't say what you're doing is stupid. Do what makes you successful and happy. Just don't be stubborn ;)

I would agree with this.

One of the directions LedgerSMB (http://www.ledgersmb.org) is going is from a framework which was originally written by one guy to something which outsources as much as possible to CPAN modules. This poses some issues, but in general it works pretty well. We probably have as much framework code as we used to but the code does a lot more. We decided not to go with other frameworks because of the dependency issues that sometimes arise.

Also I will personally vouch for #3. We started off using Std::Config for processing ini files. But this isn't well supported in distros or well maintained so we switched to Config::IniFiles and it was a pretty painless effort.

the bigger thing though is you don't have to do it all yourself. :-)

Out of curiosity, did you ever spend much time reading the code of the various frameworks on offer? Especially since you have the experience of building everything from scratch, I think you could have the same level of understanding of any frameworks you put together by browsing the code.

In Rails land at least, a lot of relatively inexperienced developers tend to have trouble when they can't google for the thing they want to implement or find it in the docs. I find that if I open up the source in roughly the area in which I need to implement something, a hook point is provided at about the right level of abstraction. Your mileage with other frameworks/environments may vary.

Beyond a point, mastery over a particular framework comes only when you look at the actual code. Just fire up a debugger with a breakpoint set in the problem area. Figure out what happens and understand why your code is breaking. Rinse and repeat for ninja level in your framework of choice.

I jump into the Rails (or other Ruby libraries) source for understanding quite often. This is good advice, but for folks coming from static languages it's really a challenge to figure out how to find stuff. I've resorted to running it all under a debugger and setting breakpoints, just so I can find out which monkey-patch (or non-namespaced, duplicate class) is being called.

2 things in particular I use:

* Bundle comes with a `bundle open <gemname>` command that opens up the gems source code in whatever your shells $EDITOR is set to. I use this at least three or four times a day.

* Pry (an IRB alternative) will tell you the file + line of the definition of the method you'd be running if you ran `show-source some_object.some_method`. You can also `ls` and `cd` your way around ruby modules/objects which has been invaluable.

If you use Pry's `edit-method some_object.some_method`[1] you can actually open the method in an editor and it'll even fast forward the cursor to the first line of the method.

[1] https://github.com/pry/pry/wiki/Editor-integration#wiki-Edit...

Definitely check out Pry (http://pry.github.com). It's designed specifically for your use case... Just start Pry, load the gems you want, and then navigate to the method/class you want to know about using Pry's `ls` and `cd` commands. Once you find what you want, either use `show-source` to view the source directly in Pry, or use `edit-method` to open it in an editor.

I do this as well - - everything from the JavaScript framework, to the ORM, to the web-framework is built or assembled by me. I even use my own special databases built on top of Tokyo Tyrant and Redis. It's basically my world where I know every part of the system. This makes me super productive and I can change anything. It's also a great learning experience. This said there is a huge problem with this approach and it's scaling your development team... It's hard for people to figure out how stuff works in an environment where nothing is standard.

My plan to solve this is to open-source my tools/libraries and switch to Flask, so at least some of the stack is familiar. Open-sourcing these tools will force me to isolate them, clean them up and write some documentation - - it can benefit other people and maybe open a pool of developers that know the tools better.

> My plan to solve this is to open-source my tools/libraries and switch to Flask, so at least some of the stack is familiar. Open-sourcing these tools will force me to isolate them, clean them up and write some documentation

Pretty accurate… I like your idea of how to solve it… You can do it the other way around too, have/ask a coder with whom you work spend at least some time on cleaning up and documenting the code… Sounds like a lot of extra effort, but they are already trying to understand and conceptualize the thing for themselves, might as well write it down…

"My plan to solve this is to open-source my tools/libraries"

Quick advice: Don't. You'll make it worse.

You're already undermining your thing in that first sentence ("switch it to X so that other people will understand it"). Turning an in-house framework into a "ready for the real world" framework is a ton of work and will invariably need to dull down the sharp edges and general case a bunch of things.

The thing is, those sharp edges are what make it such a good tool. You want sharp edges on your tools. Dull tools might not hurt anybody else but they won't be as good at doing what they do.

You've got something that works really well for you. Chances are it's so focused towards your workflow and way of thinking about the world that it just won't be all that useful to anybody but you. That's just fine.

Trying to make it useful for everybody else will only succeed in making it less useful for you.

Hey Jason. The general problem is hiring people when you use a lot of internal tools - - as some of them are made in a haste and are hackish, and most of them don't really have good documentation. But maybe you have a point and the first step could be to clean the tools up and write some internal documentation for them.

No framework approach only work for a one person team or very small team and by design cannot scale.

As soon as you try to bring somebody that will mainly "use" those tools/libraries instead of actively developing them, the tools/libraries becomes a de-facto framework to them, just a proprietary one with no community.

If/once you open-source it, it just becomes another framework competing with the other ones.

Basically: http://xkcd.com/927/

In short, if you are not rewriting everything new from scratch for every project, you are using a framework - only your own.

How consistent you are about the patterns you use must have an enormous impact on how easy it is to resume work on something three projects ago.

If you're switching between frameworks all the time, it would be even more difficult because you wouldn't have deep knowledge, but at least there is presumably a group of people somewhere to consult. If you're lucky they even had some plan when they came up with design decisions.

I can see how you avoid a lot of cruft, but how do you discipline your own projects? How much documentation do you create for your own later reference?

I just reference a piece of code where I know I've done something similar in the past, even for public frameworks like rails.

Its a really good point and Im not going to try and cover up the pitfalls you pointed out. I'm trying to document the reusable core as much as I can because 1) Im forgetful and at times will need a quick refresh 2) Im hoping that I can open source it soon and it might have a chance of helping someone that likes it. I know that producing core code to bundle into a framework when I don't use frameworks is pretty hypocritical but even so thats an intent I have for the future.

I can't speak for the grandparent but my approach has developed slowly into:

1) Consistent but evolving paradigms. In other words, let's not be static, let's keep most change happening relatively slowly. But let's review and try to fix problems as they happen, cleaning old code slowly and continuously.

2) Try to document everything to at least a basic extent.

3) Let the documentation practices evolve. Don't try to document too much too soon. Start out with a basic level. As the project matures you will have a better idea of what needs more documentation and you can spend your time on the areas that help.

4) Don't underestimate person to person mentoring.

You need to draw the line somewhere. Building your own operating system, programming language or database isn't the best idea. It is a tradeoff between time and trust.

I think it is wise to learn other frameworks and languages. It will help you with making wise decisions when developing your own tools.

Reply on news.ycombinator.com