HN user

eulerphi

126 karma
Posts2
Comments47
View on HN

Yet another reminder that passive income is the greatest arsenal in a programmers' toolbelt. Not having a salaried job gives one more time and energy, total focus. Having total focus and ability to also indulge in leisure allows one's true goals to be attacked and achieved. It's interesting that my life right now is based around 'becoming rich', well actually just self-sufficient, so I can then work on my true projects. Life after life ;-) Let's just hope I don't get too old before the passive income kicks in. Thanks for all your essays and other forms of enlightenment Paul.

The thing is that the rvmrc has the jruby version env set. So I need to load it first. And it contains an 'rvm use' which I don't want to fail. I suppose I can slim the rvmrc down to just include the environment and then all I would need to do is source the rvmrc? Thoughts?

I've had similar problems with RVM. Ultimately I used the system-wide RVM installation and this chunk of code:

  export PATH=$PATH:/usr/local/rvm/bin/rvm
  . /usr/local/rvm/scripts/rvm
  . $REPO/.rvmrc
  . $(rvm jruby-$JRUBY_VERSION do rvm env --path)
  cd $REPO
  bundle exec torquebox deploy
Definitely not ideal and I spent a large amount of hours figuring out how to use it non-interactively. I'm still somewhat worried that some things might go wrong if some of the code I didn't write in this repo attempts to call binaries directly. Basically with bundle exec --deployment, all gems are stored in $CODE/.vendor which is necessary to allow users to install their own gems, with the root installation. Bundle exec has to be used, I messed around with RVM wrappers, but they don't work with the --deployment bundler use.

I do care about hip hop. White knighting is as made up a word, as any words are. You have the mentality that if you bend over to defend women, it will somehow make you more righteous of an individual. Women don't need defending. And those terms can refer to men as well.

Let's just put this in perspective Robert. You're a KFC nerd who plays video games, knows a little programming from modding them, you don't shave your neck, hang out with your cat, and defend women's social justice with respect to rap, through some poor analysis of word frequency on supposedly derogatory "demeaning" words on women. Somehow, hoping this ill-formed sickness of a view, helps women recognize your sentimental romance toward their engendered cause. Ain't gonna happen Jack. Be a man and stop playing internet politics. And lay off the Hollandaise sauce.

Callbacks cause no resource retention other than the closure whereas context switching incurs a much greater hit.

There is no problem. The "problem"/argument mentioned is manufactured out of pure bullishness toward the current stay of things.

Kernel32 user32, advapi32, etc. Are you really going to tell me that the namespacing and naming convention for their API, which mind you, used handles and annoying type defs, was anything spectacular. I really hope you are kidding. I reverse engineered windows for years, know a huge amount of documented and undocumented api from ntdll and so on. The API is water trash, you lose when you question my know-how on this topic.

Apple was smart and basically repurposed the OSX API for ios. But they always had a good API. The original windows API is water trash. .Net is nice.

The only thing MS needs to do is go modern instead of legacy for their new phones, but is that going to happen?

Doesn't have to be an issue about social issues to not be plain retarded in terms of linguistics. Point in case: Big L. Gangsta rap that had flow and cleverness. Lil Wayne and Rick Ross don't really cut that, but I do love that song 8 Ball by Rick Ross, he's just plain fun to listen to.

Imagine trying to fit a vault in a cubbyhole meant for shoes. That's what RESTful APIs end up fighting with. I would gander that because DELETE refers to permanent deletion, whereas destroy is reversible, they chose to use the less confusing verb.

The real problem with trying to conform to REST is that there's no rigorous definition, and this leads to the same verb being used for slightly different purposes among APIs.

Harvard professor or not, he simply coined a term to refer to a new technology deprecating an old one, so much that it becomes the new market that companies compete in. Yes, the iPhone did that. Where's the debate -- it's a fact that everything became 'touch' since then. The term 'disruptive' just cheapens the discussion and brings it to a baseline level of 'startup culture' drudgery. The term is used so often around here that it's become something of a pseudo-intellectual discussion starter.