Disqus - Latest Comments for dasil003

Re: How to correctly unit test Express server | Better world by better software

Gabe da Silveira — Wed, 16 Nov 2016 19:53:42 -0000

I'm not sure it's quite so cut and dried. First of all "smallest and testable block of code" is pretty hand-wavy. It really depends on the use case where you think you'll get the most bang for the buck. Testing every helper function for instance, tends to be very brittle, if your system is well designed and has clean interfaces, the lowest level of test that might make sense is module-level testing that doesn't qualify as "unit" testing in the strictest sense, but nevertheless gives you highly performant tests that cover all the relevant use cases with less code in a less brittle fashion.

Extrapolating on that, I can imagine a Node microservice that is simple enough internally that you wouldn't necessarily gain much value from lower-level unit testing, and in that case Gleb's line of reasoning makes perfect sense to me.

Re: Deploying Django + Python 3 and PostgreSQL to AWS Elastic Beanstalk

Gabe da Silveira — Sun, 21 Aug 2016 04:37:13 -0000

Just wanted to drop a note here because I got burned trying to modify the PYTHONPATH as you've shown here. The issue is that /opt/python/current is not the only path where your code may be activated from. If you are using container_command to run anything after the code is unzipped, but before it goes live, it will actually be in /opt/python/ondeck. If you are prepending the former before the latter, what can end up happening is you are loading code from the previous deploy. This can lead to anything from complete failure to complete success, in my case leading to weird but subtle issues.

The solution I found is to just add a relative PYTHONPATH. Also, you don't need to append the old PYTHONPATH either, EB is smart enough to do the appending for you. In my project, all the modules are in a directory named `src`. So what I added to my option_settings is simply:

aws:elasticbeanstalk:application:environment:
DJANGO_SETTINGS_MODULE: myapp.settings
PYTHONPATH: "./src"

Hopefully that saves someone a headache as I spent hours figuring out what was going on.

Re: Deploying a Django App to AWS Elastic Beanstalk

Gabe da Silveira — Sun, 21 Aug 2016 04:34:58 -0000

aws:elasticbeanstalk:application:environment:
DJANGO_SETTINGS_MODULE: myapp.settings
PYTHONPATH: "./src"

Hopefully that saves someone a headache as I spent a couple hours figuring out what was going on.

Re: Writing a microservice in Ruby

Gabe da Silveira — Sat, 25 Jun 2016 12:39:56 -0000

Yeah I understand, sorry to focus on an incidental detail (what can I say, I'm a developer ;). I understand intimately why you would not want to always load the debugger.

But I still don't see how the monkeypatch version is any more efficient than the inline spec_helper code. As far as I can tell they both do exactly the same thing, the monkeypatch just does it with more overhead. Unless you are leaving out some magic where the monkeypatch is only loaded when the debugger method is actually called.

Re: Writing a microservice in Ruby

Gabe da Silveira — Thu, 23 Jun 2016 09:28:53 -0000

I'm not really following the reasoning behind making byebug a monkeypatch. The condition is the same, but the code is strictly more complex (ie. requires the exact same thing but via monkeypatch which blows away the method cache, etc). Am I missing something? Is the spec_helper loaded more than once?

Re: Bottomless Ruby Hash

Gabe da Silveira — Fri, 09 Oct 2015 01:26:07 -0000

I went through this exercise myself a few years ago and came up with something not quite as elegant, but I believe it works: https://github.com/gtd/safe...

Re: The microservices cargo cult

Gabe da Silveira — Tue, 06 Oct 2015 15:38:37 -0000

No need to be derisive about small scale operations. For every multinational that *actually* has serious unsolved scalability issues on their data there are 1000 startups whose data needs will never grow beyond what a single postgres server can deliver wasting time chasing buzzwords and overengineering their stack, actually decreasing the likelihood they will make it to the point where they *have* to scale.

Re: The microservices cargo cult

Gabe da Silveira — Tue, 06 Oct 2015 14:21:14 -0000

I'd argue that's an over-generalization. How you can cut your data model depends on the actual data model. It turns out if you don't need to scale a relational database is a very very flexible and powerful model. There are plenty of other powerful models, but I'm not buying that you can a priori abandon ACID databases and not make a lot of tradeoffs and write a lot more code. Sure it has benefits, it's just not free.

Re: The microservices cargo cult

Gabe da Silveira — Tue, 06 Oct 2015 14:03:55 -0000

You're papering over what is a very real tradeoff. There's no way that you can make a microservice interface as convenient as an in-process function call. Similarly a foreign key in a RDBMS is much lower maintenance than implementing the equivalent functionality in a distributed way. The reason you would choose a microservice approach is because both of these things are not scalable, but then again, most things don't *need* to scale either. It doesn't help to get religious about architectures in the abstract because every problem is unique and the pros/cons fall very differently depending on the nature of your application.

Re: Testing network services in Ruby is easier than you think - Weissblog

Gabe da Silveira — Tue, 25 Aug 2015 17:54:51 -0000

I would argue that if your tests are using production tokens than you have much bigger problems such as a test accidentally wiping out production data. Ideally your dev and test environments have their own sandboxed credentials which are freely distributed to your whole team, and the production credentials are locked down where only the senior people/devops can get at them.

Re: Working with time zones in Ruby on Rails — Elabs

Gabe da Silveira — Thu, 06 Aug 2015 19:13:17 -0000

I've found this article enough now that I actually Google specifically for it to get that table.

Worth noting that it is non-exhaustive however. Consider that though `Date.today` doesn't respect time zone, `Date.tomorrow` DOES (presumably because the former is built-in and the latter is added by ActiveSupport).

Re: RADIOFOBIA 166 – The book is on the table

Gabe da Silveira — Fri, 12 Jun 2015 23:47:55 -0000

Gostei demais do episódio. Ironicamente eu tô aqui para melhorar meu português. Eu sou meio brasileiro mas fui criado e morei a maioria da vida nos EUA, e sempre quando viajo pro brasil todo mundo quer treinar seu inglês comigo, ou pelo menos eles falam mais devagar e com menos expressão idiomática. Os podcasts são ótima maneira de avançar o entendimento além do nível intermediário. Acho muito melhor do que livros o jornais porque da pra ouvir como falante nativo realmente conversa sem censura.

Re: My favorite stuff from 2014, Part 2 - BrettTerpstra.com

Gabe da Silveira — Tue, 10 Mar 2015 16:55:31 -0000

Are there any posts/podcasts about the commercial replacement?

Re: My favorite stuff from 2014, Part 2 - BrettTerpstra.com

Gabe da Silveira — Tue, 10 Mar 2015 14:40:52 -0000

Hey Brett, thanks for writing this up, you always have amazing tools to share.

One thing I'm struggling with a bit is developing a tagging workflow, and a big part of the reason is that I use nvALT pretty heavily, but it doesn't have a modern tag integration. I asked you about this maybe a year or so ago and you mentioned you were thinking heavily about a post-Mavericks workflow vis-a-vis nvALT. Anyway, I don't want to jump to conclusions, but I noticed you still mentioned nvALT in part 1 of this article, and curious how you make it play with native OS X tagging?

Re: In Defense of the Midwest

Gabe da Silveira — Sun, 08 Mar 2015 23:57:03 -0000

Getting an apartment that costs a third of what the equivalent in the Tenderloin would cost doesn't strike you as a reason?

Re: The Best Cable Modem

Gabe da Silveira — Tue, 24 Feb 2015 23:31:16 -0000

Just a friendly neighborhood update from signing up for a new Comcast just a few minutes ago, they are now charging *$10* a month for modem rental.

Re: This Is What Happens to Your Bike After It’s Stolen

Gabe da Silveira — Tue, 30 Dec 2014 21:42:42 -0000

I've been mountain biking for 20 years and every single bike I've ever owned has been stolen (except my current one). The last one was a $3000 full-suspension Rocky Mountain that I had owned for 8 years (and on the third replacement frame from the manufacturer!), which I would never ever leave outside except for one time when I had to get it out of my flat while the transatlantic movers where bringing everything in, I locked it outside for 2 hours with a cable lock (the U-lock was in the arriving stuff). I probably put 20,000 miles on that thing but it was only ever outside for less than 3 hours on a residential street in London and it was nicked. So in 23 years I've had 5 bikes stolen, as much as it hurts, I have to make peace with that and realize that for as much as I ride, I'm doing pretty well.

Re: 9:30 Coffee Break: Banned From SNL | The Current from Minnesota Public Radio

Gabe da Silveira — Mon, 08 Sep 2014 10:13:53 -0000

How about Willie the Pimp by Zappa? Not sure if Captain Beefheart's unintelligible lyrics are clean or not, but I'm pretty sure you're safe.

Re: CSS is unnecessary if your layout language has means of abstraction

Gabe da Silveira — Sat, 05 Jul 2014 05:08:32 -0000

Your willfully ignoring my point and setting up a gargantuan strawman. I'll just reply to this bit:

"there is nothing inherently "pragmatic" about continuing to accumulate technical debt rather than investing in solving problems in a sane way."

Of course there is. The point is that CSS is too big to be replaced by someone who simply has a better idea. Never did I say throw up your hands and act like nothing can be done. Obviously things can be done, but they are best focused on improving CSS, because no one will be able to catalyze a replacement for CSS no matter the strength of their technical argument and solution.

Re: CSS is unnecessary if your layout language has means of abstraction

Gabe da Silveira — Fri, 04 Jul 2014 10:55:55 -0000

The web is a textbook example of worse-is-better. The web won precisely because of it's simplicity. CSS succeeded because it was a solution to the problem at hand. Then it incrementally improved and garnered true cross-platform and cross-media support along the way. Today it looks like an ill-designed monstrosity, but it also has solved more problems than any one person or technical team can fathom. Complex systems are *never* designed, they *evolve* from simple systems. Sure everyone thinks they can design something better, but only for the subset of problems they are considering. Supposing you put this superior solution out there it would be pure and clean and so much more elegant, but in order to cross the chasm and provide a suitable replacement for CSS it would have to pass through so many trials by fire that the end result would be so maimed and corrupted that the next guy will write another article just like this.

So while the criticisms are legitimate, there is no solution. There is no known intelligence broad enough to encompass and produce a superior solution to what we have today. By all means design and build better solutions to specific problems—that is part of the evolution—but to think that CSS will be replaced by something which somebody conceives of to be better designed is pure hubris.

Take a step back and look at what the web has done. It is the most ubiquitous media platform in the history of humanity. It is orders of magnitude more portable than the most portable C code. It is available on screens large and small, can be printed, can be served to the disabled both blind and deaf as well as presumably a combination, any modern computer can access it whether it's a POSIX system or proprietary or something else. This is a monumental achievement, so to say that CSS is poorly designed and should be replaced is to through out the baby with the bathwater.

Re: The Old Reader: behind the scenes - Let’s Keep the Internet Dumb

Gabe da Silveira — Wed, 30 Apr 2014 06:25:49 -0000

I'm picking a fight because your arguments are technically vague and you are redefining the common meaning of "smart" in a way that mirrors the talking points of the telecoms who want everyone to believe that the "smart" networks they want to build are to ensure fairness.

I did not ignore your definition, in fact your definition of "raw TCP/IP" is actually broader than mine as it includes Layer 4 (TCP) whereas I was saying fair allocation can be handled at Layer 3 (IP) or possibly lower. You speak of TCP/IP as a monolithic thing as "smart" as being something built on top of that, however that is technical nonsensical. TCP/IP is not a single unit, it is a collection of protocols and is agnostic on many issues to make for easier implementation/compatibility. Your insistence on your own definition of "smart" that flies in the face of common usage is hurting the cause you claim to support. It's particularly ironic since you were arguing to have a common definition, but the definition you propose is completely made up of thin air and does not reflect common terminology (however vague that may have been to start with). That's why I'm picking a fight.

Re: The Old Reader: behind the scenes - Let’s Keep the Internet Dumb

Gabe da Silveira — Tue, 29 Apr 2014 17:39:36 -0000

Okay let me just respond verbatim then:

"In a dumb network, Pandora can hog all the bandwidth it wants, because the network doesn't care. In a dumb network, your neighbor can download gigs of data 24/7 and starve out your internet, giving bad quality of experience.".

This is factually incorrect. A smart network is not necessary to prevent this from happening.

Re: The Old Reader: behind the scenes - Let’s Keep the Internet Dumb

Gabe da Silveira — Tue, 29 Apr 2014 16:31:53 -0000

Sorry to put words in your mouth, but your discourse is harming the cause, here's why:

The type of capping and throttling you're talking about to ensure fairness does not require a particular smart network, it can technically be done at Layer 3 and below of the OSI Network Model (http://en.wikipedia.org/wik.... With the right architecture, fairness can be assured even lower, at the physical network level, but in any case, there is very little intelligence required to make this happen. You might as well say that IP routing itself is a "smart network" for all the complexity that is involved.

What ISPs want to do with, and what "smart" means in this context (if indeed we need to make a binary distinction between dumb and smart, because of course its a very smooth sliding scale, but I digress.) is mucking about in Level 4 and above. Of course this type of "smart" network is very important, and is included in most router even down to very cheap consumer routers. This is what lets you prioritize Quality of Service (QoS) for, say, Netflix over software updates, or parents' computers over kids' computers. That is great to have on your own private network to make the most of your limited bandwidth, but it's fundamentally terrible for your upstream ISP to decide to this in the name of fairness. In your example you cite your neighbor starving out your network by saturating it with Pandora, and your imagined solution is for the ISP to say oh, this user is using too much Pandora and it's hurting his neighbors connectivity. But the problem is not solved by the ISP judging traffic, it's solved by splitting bandwidth evenly. This requires nothing remotely approaching "smart" networks, to make ISPs with a monopoly and a profit motive in charge of "fairness" is to open Pandora's Box (sorry, couldn't resist the pun), and it undoes the brilliant vision of the original architects of TCP/IP which led the innovation we've seen over the past 30 years.

So for the love of god, please don't say "smart" networks could be a good thing. That's just muddying the waters for the ignorant. No, "smart" networks are not necessary for fairness, in no way shape or form.

Re: The Old Reader: behind the scenes - Let’s Keep the Internet Dumb

Gabe da Silveira — Tue, 29 Apr 2014 12:07:21 -0000

You're reframing the debate to a non-issue that has nothing to do with Net Neutrality in the political sense. You're talking about bandwidth and throttling and capping for individual users. This requires only the most basic network equipment, and frankly it's only a consequence of bandwidth being shared on local switches (given sufficient fiber and switching capacity in the last mile this issue could completely disappear.

When you look at what telecoms want, it is the ability to do deep packet inspection or other methods of controlling application bandwidth at a higher level. Never mind that the customer already paid for their bandwidth, and Netflix already payed for their bandwidth, and that the Internet is made of Tier 1 networks with peering agreements to ensure global connectivity. They want to double dip and charge one party to take a certain share of another party's bandwidth, even though both parties already paid. So if every person pays an extra $1000 to AT&T then the net effect will be everything is exactly the same except AT&T is 3B dollars richer because AT&T hasn't invested in any new network capacity, they've just collected money from everyone to maintain the status quo. This is what Net Neutrality is about, not per-user throttling which is basically a non-issue and has already existed since forever.

Re: Hunter-gatherers belly bacteria show us how little we know about the world within our gut

Gabe da Silveira — Wed, 16 Apr 2014 15:16:06 -0000

The "back-to-nature crowd"?

Have you stopped and asked yourself how many people in the western world are really going to go out and start eating unwashed food and compared it against the number of people feeding their kids McDonalds and Lunchables or whatever hugely profitable snack food has been engineered using cheap grains subsidized at the behest of a farm lobby to produce an arbitrary surplus of "food" with nary a bit of dietary research entering into the equation?

No my friend, I don't think you need to worry about the bugbear of hippies and raw foodies corrupting our perfectly healthy convenience lifestyle. It would perhaps be wiser to take a look around at the legions of obese children and diabetics and ask yourself what are we going to do about that?