drewolson
Re:Announcing new tools, forums, and features
on Wednesday September 14, 2016 @03:04PM (#12500214)
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.
Specify Your API
Re:Experimental Dependency Vendoring in Go 1.5
on Thursday June 11, 2015 @05:03PM (#9702422)
Ah, thanks.
Re:Experimental Dependency Vendoring in Go 1.5
on Thursday June 11, 2015 @03:24PM (#9701738)
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.
Re:Experimental Dependency Vendoring in Go 1.5
on Thursday June 11, 2015 @03:01PM (#9701596)
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.
Mave Public Beta – A drop-in SMS invite page
Re:Reproducible Builds in Go
on Wednesday April 29, 2015 @11:21AM (#9458910)
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?
Re:An Empathetic Functional Language
on Friday March 20, 2015 @12:33PM (#9238664)
Author here. You're right. I removed references to "pure" in the article.
Re:Just-in-time packager for GitHub repositories
on Tuesday February 10, 2015 @01:08PM (#9028762)
Does jitpack currently support repositories in Github Enterprise?
Composable Queries with Ecto
Re:Phoenix – Elixir Web Framework
on Saturday November 29, 2014 @10:03AM (#8673870)
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.
Braintree V.Zero SDK – Faster integration, drop-in UI, and pay with PayPal
Node Streams for APIs
Re:Pairing vs. Code Review: Comparing Developer Cultures
on Tuesday December 17, 2013 @12:36PM (#6922395)
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.
Understanding gen_server with Elixir and Ruby
Re:Golang Diaries II
on Monday July 15, 2013 @10:21PM (#6049701)
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.
Re:Clojure core.async and Go: A Code Comparison
on Thursday July 04, 2013 @03:31PM (#5992114)
Thanks (and thanks to pron). I've updated the post to include a warning against using Thread/sleep in go blocks for "real" code.
Re:Clojure core.async and Go: A Code Comparison
on Thursday July 04, 2013 @03:05PM (#5992025)
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.
Clojure core.async and Go: A Code Comparison
Performance Improvements Using Judy Arrays
Springboard: Full-stack HTTP testing for Express apps
Blogging with Mobile in Mind
Testflight - Painless HTTP testing in Go
Re:Show HN: Redis Dashboard
on Monday June 18, 2012 @10:05AM (#4126450)
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]?
Rails Mass Assignment Protection in the Controller
Ping Pong is Serious Business
Re:Agile is a Sham
on Wednesday March 28, 2012 @09:49AM (#3766206)
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?