drewolson

Reviews are very exciting, but seem to be unable to fit the following use case:

I want to setup a repo such that a subset of collaborators (or organization members) can merge reviewed PRs to protected branches. I want the rest of the users to be able to create new branches and submit PRs from them, but _not_ to be able to push to protected branches. They should _only_ be able to land code in protected branches via reviewed PRs (via the merge button).

Is there a way to achieve this now that I'm missing? Gitlab's more granular user roles + permissions allow this.

Ah, thanks.

Can you reference the part of the proposal that states this? I'm reading the following points:

$GOPATH/src/foo will be imported as foo by non-main package $GOPATH/src/mypkg/p.

$GOPATH/src/mypkg/external/foo will be imported as foo by a non-main package p anywhere, when p is being built as a dependency of command $GOPATH/src/mypkg/c.

It seems to me this is saying that libraries will use external packages only when built as a dependency of a main package. Again, this means library authors are out of luck.

Am I understanding correctly that this proposal again side steps / ignores pinning dependencies for libraries? To me, this is the biggest current problem in the ecosystem and, as a library author, this doesn't solve any of my issues. I hope I misread somehow.

How is this different from godep[1] other than being the root of its own GOPATH and having a different naming convention for the location of vendored dependencies?

[1] https://github.com/tools/godep

Author here. You're right. I removed references to "pure" in the article.

Does jitpack currently support repositories in Github Enterprise?

This whole "framework fatigue" thing is going reductio ad absurdum. Convenience is not bad. _Too_ much convenience traded for opacity is bad.

As someone with a Phoenix app running in production, I can tell you that this framework hits the sweet spot of providing lots of value without requiring the user to learn too much. The abstractions it provides, especially the router and rendering layers, are very welcome. And I'm saying this from the perspective of someone who has built a few smaller vanilla plug applications.

Let's not throw the baby out with the bath water here just because rails went a little too far with the magic.

I'm confused, you're questioning the author's sincerity in expressing his own enjoyment of pair programming?

I deeply enjoy pairing. I know quite a few folks that do as well.

I think the point is, if you write map like this you might as well be using a dynamically typed language in the first place because you're deriving no benefit from the type checker. In fact, you're just using casting to completely circumvent it.

Thanks (and thanks to pron). I've updated the post to include a warning against using Thread/sleep in go blocks for "real" code.

Author here.

From what I've read/seen, the go blocks are lightweight thread-like processes multiplexed onto a thread pool. You may be correct about using Thread/sleep, ideally I would have used (timeout ...) and then pulled off the channel. However, I didn't want to introduce the concept of channels too early in the post, so I felt Thread/sleep worked as a compromise.

I noticed you're using tornado but appear to be using the standard (non-evented?) python redis library. Does using this library block tornado's event loop? Did you look at other tools like brukva[1]?

[1] https://github.com/evilkost/brukva

A fun anecdote is to consider the belief the TDD crowd entertained that, by creating tests for a problem you couldn’t solve, you could somehow evolve a code that passed the tests and therefore solved the problem!

I'm all for a healthy debate of TDD, but the above statement seems ridiculous to me. For me, TDD helps with two main things:

- I specify the behavior I'm adding/changing before I implement it. This helps document the change I believe I'm making.

- I feel more confident when making changes to a large codebase.

TDD works for some and not for others. There are very interesting arguments to be had about the subject. However, can we please stop acting as though TDD advocates view their tests as having psuedo-mystical powers to solve problems automatically?

When we began building our Python library, we looked at both django[1] and sqlalchemy[2] for inspiration in designing our search DSL. Your example seems to closely match the django style. We preferred the sqlalchemy style, but both are solid choices.

[1]http://docs.djangoproject.com/en/1.2/topics/db/queries/#chai... [2]http://www.sqlalchemy.org/docs/ormtutorial.html#common-filte...

This is a great point and is something we're planning on adding in an upcoming release of our Python library.

kevingadd -

We tend to use var when the return type is obvious, but we wanted to be explicit in the examples. Unfortunately, LINQ is not an option for us as we support .NET 2.0.

Your C# and Python predicate examples are quite readable, but in this case they don't work for us. The return type of each of these statements would be true or false, whereas we are building XML requests to be sent to a server to perform the searches. The call to Amount.Between(...) builds an XML node behind the scenes representing the search data.

Drew Olson (Braintree Dev)

In javascript, functions are closures. This means that the function "closes" over the environment in which it was defined. In the above example, the function has access to the sum variable because it was available at the time the function was defined. It is then free to add to that variable when the function is called at a later time.

I'm the author and I appreciate the insights. I wrote the article about what I consider to be building blocks of metaprogramming. I don't agree at all that eval() is the only piece of JS code that is metaprogramming. I believe that being able to dynamically define methods on objects at runtime is an example of "code that writes code" and hence metaprogrmming. YMMV.

I have to second The Road. Any book that I finish in a single sitting has a special quality. I would say it is my favorite book of the past 5 years and in my top 10 of all time.