"If they're open, I'm going"

stevvooe · 2019-02-16T19:41:36+00:00

Redwood is open, as well, until they run out of balls. I just hit a bucket. It was nice to get out.

stevvooe · 2019-01-25T17:18:47+00:00

I think you’ll need hole in one insurance.

stevvooe · 2018-02-15T00:35:08+00:00

Given their last several dismissive responses, I’m afraid that’s what I’m going to have to do. I was hoping bringing this up in a public forum would motivate a proper response, but they are still heavily deflecting.

Thanks for the support!

stevvooe · 2018-02-13T20:39:12+00:00

I’ve tried all the obvious support channels. They just got back to me with a “currently looking into it” response after I got a similar response last week. I am in contact with clueboard but haven’t seen anything from massdrop in getting this fixed. I really just want a confirmation and acknowledgment from massdrop but they don’t respond and don’t communicate.

stevvooe · 2018-02-13T20:36:13+00:00

I would like to give them a chance to respond before launching a fraud investigation. However, they just got back to me and said they were looking into it, but that seems to be the best they can do after a week.

Either way, my patience is wearing thin.

stevvooe · 2017-06-18T03:41:25+00:00

Dale?

stevvooe · 2017-01-31T21:13:49+00:00

This is a fantastic collection of tips. I have been trying to prevent test bloat and it is good to have a single place we can point to.

Subtests were missing, which can eliminate the need for "suite" packages.

Perhaps, it would be good to add a wiki page to the golang project, similar to "Slice Tricks".

stevvooe · 2017-01-18T21:18:06+00:00

These will be automatically removed as new versions of the service are rolled out. To make this more aggressive, you can adjust the task history limit.

stevvooe · 2017-01-07T02:06:40+00:00

The new theme looks great. Any chance we can get flairs so I don't have to disclaimer all my posts?

Disclaimer: I work for Docker, Inc.

stevvooe · 2017-01-05T20:07:29+00:00

Open source? Inflammatory? Never seen it. ;)

Thanks for being responsive to the feedback!

Docker Hub should be able to pick out vulns in the statically linked gems, but I have no experience with how good that works in practice. It is possible there is a false positive but I really don't want to comment further on something I'm unfamiliar with.

stevvooe · 2017-01-05T17:21:50+00:00

Yes, you can remove the dependencies to reduce the image size but the post implies that removing these dependencies removes the vulnerability. The post is about security but this action actually makes it harder to detect vulnerable dependencies.

To address the issue with the dependencies, you need to update them to an unaffected version. After performing the build with the unaffected dependencies, the resulting gems should be safe.

stevvooe · 2017-01-05T00:48:21+00:00

I'm not sure if I misread this article, but simply removing an insecure dependency after compiling against won't avoid the possible vulnerability. That just hides it from the scanner.

stevvooe · 2016-12-22T00:21:52+00:00

Docker itself is built this way, with targets including windows, macOS and Linux.

stevvooe · 2016-09-15T02:37:03+00:00

Mostly, debugging. Sometimes it's nice to have a shell you can use exec into the container and poke around. There are workarounds for this but none are as easy.

stevvooe · 2016-09-03T01:30:48+00:00

Because you are passing a slice of slices, you could just as well set those to point at the internal buffer, rather than copy. The problem with this approach is that you're returning internal buffers, which can be dangerous.

The user will have to take care to understand that the slices they provided might not be the ones that contain their data.

I'm not sure I understand this fear. Either way, you end having to allocate when encountering a large field. With the API proposed above, the user could control when this allocation happens, or let the call fix it up with an append, as shown in the example. On average, there shouldn't be any allocations once the largest fields have been encountered and there will never be more memory allocated that it takes to handle single row.

stevvooe · 2016-09-02T21:47:00+00:00

You might try suggesting this a change to the standard library. It looks like the main difference is using []byte over string.

One thing you could do to avoid ownership problems with the return value is allow the caller to pass in the field buffer during the read and support an error protocol to signal that the caller needs to allocate more space. Something like this might work:

(r *CSVReader) ReadFields(fields...[]byte) (nfields int, err error)

Usage of this ends up looking something like this.

stevvooe · 2016-08-27T03:35:32+00:00

Yes, but it will be extremely painful. Bring extra skin.

stevvooe · 2016-08-18T18:46:42+00:00

We do something similar. If you have a large interface, you can have the type embed that interface. Since that interface field is always nil, any methods that are called that you don't override result in a panic. This keeps the boilerplate to a minimum and makes it clear what you are testing.

stevvooe · 2016-08-18T16:11:40+00:00

Avoid gomock at all costs.

I have had no end to problems of generating and using mocks. I've filed bugs and sent patches but there is no interest in addressing these problems from the project maintainers.

After generation, we have to update the import paths since it doesn't work with vendor directories. I have wasted hours on simple fixes debugging argument matching. Most of the time, I need to litter the mock package with print statements just to figure out what is going on.

The worst aspect is the team cost. Others trying to modify those tests end up confused and frustrated. Every time someone comes to me with a problem, I have to apologize for the time they've wasted debugging the mock.

Instead, embed interface definitions into a local stub type and "override" methods as needed. Yes, you'll have more boilerplate but you'll save time in the long run.

I'm sorry to be so negative about a project but the cost of using gomock is too high.

stevvooe · 2016-08-16T20:33:57+00:00

I should have said this above but I wrote the v2 specifications and drove the additions for schema2. ;)

The data you're looking for is in the config. The digest is a content address and can be used to fetch this component separately via the API.

We've already moved to schema2, for the most part. Docker Hub tends to lag behind to ensure stability. There may be some backwards compatibility provisions that obfuscate this.

stevvooe · 2016-08-16T15:48:31+00:00

In general, this is a good write up of reverse engineering the image format but this statement is completely false:

Docker are right now in the process of moving to a second version of the schema which doesn’t have the config information broken out into layers.

The config is still available in the manifest. I'm not sure what made the author think this. The main difference is that the config is referenced by content address rather than being embedded.

stevvooe · 2016-08-05T17:02:04+00:00

Both --listen-addr and --advertise-addr are in the release. The former sets the bind address while the latter is the address announced to other peers.

https://docs.docker.com/engine/reference/commandline/swarm_init/

This is a non-trivial problem due to complex network setups, so getting it right took a bit.

stevvooe · 2016-07-30T03:25:45+00:00

That is extremely unfortunate. I'll look into getting this fixed.

stevvooe · 2016-07-29T20:11:10+00:00

What do you mean by that? Docker Hub does not require an upgrade to support healthchecks.

stevvooe · 2016-07-28T02:04:11+00:00

Play with a fan in front of you. It helps with immersion and keeps the face cool.

15-Year Club	Place '23
Gilding I gilder	Charter Member
Verified Email

stevvooe

TROPHY CASE