dkubb

Did you mean "brew install --with-hpn openssh"?

The only one I know of that fits this criteria is Primecoin, its proof of work function is to mine prime numbers.

I haven't heard of any others, but I'd be curious to know about them.

I don't know about full time, but sometimes when a client asks me to extend a piece of software I'll ask the upstream maintainer if they'll accept a patch for the change (with permission from the client of course). The client gets software with the fix included, where they don't have to worry about checking each future upgrade to see if the fix broke something.

It's not perfect, but I've used sourcify [1] to get Proc#to_source. I would much rather see this built into ruby itself, since there are a bunch of tools I would build with it available, but this works fairly well in practice.

[1] https://github.com/ngty/sourcify

Contact Braintree if you're concerned. There are processes in place where they can transfer payment information (including credit cards stored for recurring billing purposes) to another payment gateway.

I've often wondered if we could store issues in a separate branch.

I would also love to see these kinds of reminders. Going to the movies is fun when it's something I really want to see, but I probably watch 5-10x more at home than I do at the movies.

I just saw a PoC on twitter a few minutes ago. I tested it locally and was able to run arbitrary ruby code via YAML.load, including shell commands.

This is something I've done before, and I quite like it.

I didn't realize how enjoyable it would be until I was a team lead in the early 2000's and I started doing code reviews and established peer reviews in my team. The team would review the code with someone else in the team, and when they couldn't find any issues they'd pass it to me for final review and deployment. The process was sort of gamified (without realizing it, I later found out their goal was to get it by me without me flagging anything).

Since that experience I've been freelancing, I usually try to establish the same environment in the teams I work with. I sometimes do pure mentoring, where I'm not working on the day to day aspects of the project, and am just reviewing pull requests and offering suggestion; but this isn't quite as common yet.

Lately I've been getting more gigs to act as a mentor, and that's pretty cool, but I don't think it's something I would want to do full time. I've found the mix of working with the team and mentoring feels perfect to me.

By "built a lot of what you're using now" he could mean he built a large part of the site that hosts the article.

My wife drove down the freeway and forgot her iPhone on the roof. It flew off at about 90 kph (about 55 mph). It took her about 10 minutes to find the next turn-around and make it back to the phone. To make it worse she saw at least one car run it over as she was walking to pick it up.

I opened up the case and there's not a scratch on it. Aside from some dust the phone is still in mint condition. The case is nearly perfect too aside from one tiny bent plastic part under the rubber shell.

I won't say which case it is because I don't want to sound like an advertisement, but IMHO it's totally worth it to get a good one.

The current version of ARel is not a relational algebra library, it's an SQL compiler according to Aaron Patterson [1]. Many of the concepts and names for internals are based on SQL not RA. There's nothing wrong with that, it's a pragmatic choice for Rails given that ActiveRecord is an RDBMS only abstraction.

I've been working on a relational algebra library for ruby (tentatively) called veritas [2] where the sets are closed under all operations.

Given that it's a higher level abstraction than ARel the trade off is that there's not a 1:1 mapping between it's pure RA ops and SQL operations. I err on the side of producing SQL that will returns the correct results, which means some of the queries are a bit verbose. I consider that only a temporary problem though; I believe I can get to the point where most common queries are identical to what you'd write by hand. I'm focused on correctness before performance.

I've also written an optimizer [3] that takes the RA AST and rewrites it to be smaller and more efficient. It handles lots of the low hanging fruit, but there's still room for improvement. The advantage to this approach is that it simplifies the AST for all targets, not just SQL. There's even room to do per-target optimizations, which is nice because there is often multiple ways to form a query, and some approaches may be more efficient than others on different backends.

[1] https://github.com/sconover/knit-js#footnotes [2] https://github.com/dkubb/veritas [3] https://github.com/dkubb/veritas-optimizer

I don't mind talking about it here. I've worked solo for a number of years after leaving a stable full time job. I did a lot of open source work and through the community I've come in contact with a group of devs who work together on client projects.

The people running the coop are responsible for finding us the new contracts, and they add something on top while I get to charge decent rates. I know I could probably market myself and earn the same thing without the middleman, but I don't have to worry about keeping the pipeline full, billing, negotiations, etc.. having someone else handle that frees me up to focus on development.

The nice thing about this arrangement is that since we're a team we can work on larger projects than I would otherwise be able to bid on myself. Instead of having to juggle 5 or 10 projects to fill all my billable hours in a month, I can easily do it with just a couple. I'm also able to go much deeper and work on 6-12 month contracts, rather than doing short, trivial projects.

As someone who is interesting in writing more Haskell, I've heard all the "if I get it to compile it works perfectly the first time", and I wonder if people are missing out on what proper TDD can bring them.

At first TDD becomes a way to assert your code does what you expect. After a few years you begin to use it as a design technique, and the correctness argument becomes less and less of a reason for using it. It's more of an (albeit nice) side effect at that point. I can write code that I test after the fact and still get the same correctness benefits, but the feedback I get from testing my design is gone.

Maybe I'm missing something, but I don't know if just having an excellent type checker is enough to provide the same quality feedback loop as well executed TDD does.

IME the remaining skilled engineers want to work remotely.

The last 8 years I've worked almost exclusively for US based businesses as a remote contractor. It's the best of both worlds, I can charge competitive rates but have a relatively overall lower cost of living and access to free healthcare. Taxes are higher in Canada, but it works out that I'm way ahead than if I lived in SF or NY.

The downside is that I occasionally do miss the one-on-one interaction I get with team. It helps that I've begin working for a co-op, and I'm often working as a team with the same devs on new client projects. I also do lots of oss work, which helps me keep my skills up by working on challenging projects as part of a community.

That's the thing though, everyone has a different perspective of where they are working on the pyramid. One person's peak is so far below another's abstraction level as to be considered part of the foundation, and vice versa.

In oss, I think you can make contributions in two ways: refine or invent. To do either of these you have to learn the past.

Even if all the only result is an exact clone of BeOS an entire group of developers will have learned a whole lot about something state-of-the-art at the time it was created. That's knowledge that was previously available only to a tiny group of people.

I don't think anyone is advocating this kind of development. In general you can't trust anything the client tells you, so to release information to a client that has not provided proper authentication credentials to the server is a mistake.

I've often thought that frameworks should be built on top of standardized native apis, poly-filled when necessary. I imagine a time when browser specific hacks will be outside of the frameworks and "pushed down" to something lower level; ultimately shared across several frameworks rather than siloed off like it is now.

A friend told me one time about a theory he read about, that has to do with how the brain interprets goal accomplishment with sharing your goals. Apparently, the idea is that if you go around telling people about your goals the brain gets the same kind of "high" as if you had actually accomplished them. This diminishes the likelihood of you completing them because in your mind you've already gotten the benefit and the rest is just a lot of extra effort.

I wonder if it's the same thing with Facebook and other social networks. By "socializing" on FB the brain gets the same kind of high as if you had actually spoken to the person, thus making you feel satisfied with the social interaction so you don't seek them out.

Another idea I haven't seen mentioned is having a project building properly via travis-ci.org or some other CI system shows that the project is actively maintained and passing an automated build. Perhaps other metrics like code coverage could be used as well.

It's possible that within the Mac App developer community he might earn goodwill by giving it away, but I don't think it's going to make a difference for the average users.

I can't recall the names of any dev shops for the OSX products I have purchased, much less the ones I use for free.

I have no problem with people selling simple tools that make built-in features more accessible.

pv - very useful to put in the middle of a series of piped commands to provide feedback on what, if anything, is happening.

I could've used this many times to catch cases where the amount of work being performed didn't match my expectations; usually an indication of an incorrect assumption or mistake I had made. Instead I sat there waiting for something way longer than I should've, only because I had a bad feedback loop.

Ripper can only parse static source, while ParseTree can give you the AST as it is at runtime. So with Ripper you give it the name of a file/line number and it can parse it, but it can't get any contextual information available at runtime, or anything that might've changed at runtime. With ParseTree I can give it a Proc object and it can parse it in whatever state it is at that point in time.

In a nutshell, how sourcify works is it gets the source_location for the Proc, which gives you the file name and line number. It uses Ripper to parse the file, and the Proc starting at that line number. It provides an object that can be fed into SexpProcessor to extract information about the block of code within the Proc.

Since it's bound to Proc#source_location one of the limitations is it can't distinguish between two or more Proc objects defined on one line (eg users.select { |u| u.id == 1 }.select{ |u| u.name == 'John Doe' }). However, that doesn't seem to be too much of a limitation.

Well, on 1.9 it's not quite as nice as 1.8. The ruby-core team decided to change ruby so that after parsing the source the AST would be thrown away as part of some kind of optimization. That means things like ParseTree don't work anymore, and you can't inspect the AST of a Proc at runtime.

However, with sourcify you can sort of emulate the 1.8 behaviour, but it's not perfect. It uses ripper to parse the file where the Proc is defined, and then provides the same callbacks that ParseTree does. It mostly seems to work, but it does run into problems if two Procs are defined on the same line, eg: users.select { ... }.select { ... }.

I'm actually a little disappointed that ruby-core decided to go in this direction. I think that decision will end up costing the community because it makes it harder for runtime introspection of code. It means less tools will be written on top of the runtime, and things like Ambition become harder if not impossible to do reliably. I'm glad to see Rubinius is going in the opposite direction though.

I wrote an Ambition-like API for DataMapper a couple of years ago and still keep it updated: https://github.com/dkubb/dm-ambition

It uses sourcify (which uses ParseTree on 1.8 and Ripper on 1.9). The semantics are identical to standard Enumerable API. In fact, it's not recommended, but you can turn off dm-ambition and the expressions will still work as-is -- only instead of generating a query from the block it iterates over the results and filter in-memory.

How does String#prepend compare to String#insert in your benchmarks? eg. "bc".insert(0, "a") # => "abc"

The DataMapper ORM allows you to use SQL but still return domain objects: http://rubydoc.info/github/datamapper/dm-ar-finders/master/D...

Maybe the gp doesn't know about it or chooses not to use it, but it exists.

I'm a freelancer, so I get to "start" at different companies several times a year, and I'm always surprised by how inefficient things are. However, I'm equally surprised by the fact that a few months in I've forgotten what the bottlenecks were because I've gotten acclimatized.

So by the time I'm in a position to influence those processes I can't remember what the problems were.

What I started doing was take notes the first few days/weeks of what is required to get setup, or where things could be improved. Then I refer back to them every few weeks, and will sometimes up up with solutions and start sending them up the chain.

I've used a similar technique to this called Mutation Testing to find code that wasn't tested by a unit test.

It doesn't use a GA, but it's still pretty neat. It parses the code into an AST and then mutates each node in the AST, rerunning the tests to see if they pass or fail. They are supposed to fail; if they continue to pass, it means a state isn't being tested.

The computer acts as my assistant tracking down cases I forgot to test, so that I can write the test to catch the mutation. Sometimes it even finds sections of code that are impossible to reach normally, allowing me to remove the dead code paths that I might otherwise have missed.

I think it's probably safer to proceed with the assumption that any sufficiently motivated government can seize your physical machine anytime they wish.

I should note that I'm not disagreeing with you, I just think there are more important considerations to make before physical location of the data.