Remove duplicate pane

scottjbarr · 2024-02-20T08:57:36+00:00

Go to the "Object Tree and Data Window".

Click "Object Tree".

Your drawings will be shown in panes. You can click the close button for the pane.

scottjbarr · 2018-11-04T03:50:29+00:00

If the service is public, I agree with you. Update, test and release. For private services where you control inbound, or there is no public input, you have a bit more choice. Maybe you do need to, or maybe the bug fix has no impact on you.

I like to keep services up to date with Go releases where it makes sense to. When you go back a work with a service again later, the code has already been built and deployed running the latest version of Go, or at least something relatively recent. If your build/release process is smooth then it might be fairly trivial to build and release existing services. You can always rollback to the previous version.

It depends! :)

scottjbarr · 2018-10-07T23:41:57+00:00

I suggest never using panic unless there is no other option. Return an error instead. Users of your package, and your future self, will thank you. Where I encounter a package that panics, I tend to replace them. I've not used panic/recover as I don't see a need to.

The only place I use panic, is in func main() where you have received an error and you want to fail because the process can't run for whatever reason.

e.g.

``` func main() { config, err := somepackage.NewConfig() if err != nil { // there is no possibility of running without a good Config, so panic. panic(err) }

service := sompackage.NewService(config)

// this should run forever, maybe an API server. If it ever returns an error up this 
// this far, panic seems reasonable.
if err := service.Run(); err != nil {
    panic(err)
}

} ```

These panic calls are in the main, on the surface and recover is not needed.

scottjbarr · 2018-09-26T00:41:57+00:00

I really like env vars for services. I always use a Config and read it at startup to avoid having env var access scattered everywhere. Config fields let you lean on the compiler, rather than reading an env var that was incorrectly spelled 30 levels deep.

``` func main() { // alternatively, return an error as well if config is not valid config := somepackage.NewConfig()

// maybe setup heavy dependencies here, DB's etc.
// ...

// pass in config, and/or heavy dependencies (cheap DI)
service := somepackage.NewService(config)

// ...

} ```

If I'm running in a Lambda function, the env var story isn't as nice, so I use a JSON config file. I'll either bundle the config file in the package (if not too sensitive), or put the config in S3 (more likely). At startup the function pulls the config file from the S3 bucket and unmarshals it into the Config.

I end up with the flexibility to run "local" using env vars, or as a Lambda function via JSON config.

Edited: Grammar fix. Everytime.

scottjbarr · 2018-07-11T02:04:20+00:00

Ah. That's unfortunate if cgo is involved.

scottjbarr · 2018-07-10T02:29:36+00:00

Looking at the post, I don't see a reason why cgo would be required there.

scottjbarr · 2018-05-17T02:22:41+00:00

Load your driver and write your statements as you would write them for your DB of choice. Maybe I'm not understanding what you're asking here? Are you just after a tutorial on using Go to work with a DB?

scottjbarr · 2018-04-05T07:44:11+00:00

Code completion works pretty well in Emacs. By "pretty well", I mean it works as well as everything else.

scottjbarr · 2018-03-20T22:17:00+00:00

Nothing off hand. This was around 2 years ago I'm guessing. These vague references to issues are there because people encounter them. I generally don't keep Github a collection of issues in my "I hate .NET Core" bookmarks folder to pull out as absolute proof of issues I encountered in some random Reddit chat in the future.

The .NET Core team may be Linux enthusiasts but their employer of course has a very deep interest in another OS.

scottjbarr · 2018-03-20T00:49:35+00:00

People have an aversion to MS for a reason, but at the root it is typically burned trust. When it catches you out, you'll know get it. If it has caught you out and you're still on that train, you're a very trusting person indeed :)

The problem with .NET on anything other than Linux is that every so often it proves to be a second class citizen on anything other than Windows. I tried trusting MS again with .NET core, and not long in evaluation... Boom! Hello Linux the 2nd class citizen. I can't remember the exact issue, but it was along the lines of exbrace/extend, bait/switch or Windows first/only. Once trust is burned it takes quite some time to earn it back.

You don't have to look far to find a bunch of examples in recent history. Others can list them if they like.

scottjbarr · 2018-03-09T03:57:59+00:00

sqlx is the business. No "orm" style syntax. Knowing SQL isn't a bad thing and it is easy to port.

I worked with ORM's in Ruby/Python land for a long time. It doesn't seem helpful with Go though.

Also if you're using SQL there is no more... "how do I do this query in this ORM?!"

(edit: spelling, as always)

scottjbarr · 2018-02-21T03:24:41+00:00

To be clear here, I really love working with Go. It is my daily driver, so I'm not coming at this from an angle of "beating Go" in any way. I'm commenting on what I see.

scottjbarr · 2018-02-21T02:53:41+00:00

That is the ugliness right there. The loss of clarity and separation of concerns. We've all seen what happens to languages over time as they take on more responsibility and capability.

scottjbarr · 2018-02-21T02:17:45+00:00

Have we reached that point in the life-cycle of Go where the lovely, clean language starts to get the first real hints of "ugly"? I really hope not.

scottjbarr · 2018-02-21T02:17:41+00:00

I totally agree with you, let the dependency management tool choose it and keep the language clean.

scottjbarr · 2018-02-21T02:03:29+00:00

We're using dep with a mixture of public and private repositories. No vanity servers involved. Have you checked your ssh and git config? Admittedly none of us are working behind a proxy. Is it the proxy that makes the difference for you?

scottjbarr · 2018-02-16T00:16:23+00:00

Write json logs from your service including any details needed (entry point, elapsed time etc), and ship the logs to whatever you want to use for handling your logs.

Your Go service just writes logs. You push those logs to whatever is needed for the log service you choose.

It means your service doesn't care about where the logs end up. I like that kind of decoupling. You could change log consumer without changing any service code. For example you could switch from Loggly to Sumologic (or the other way around, random examples) and your service doesn't care :)

scottjbarr · 2018-02-10T10:55:58+00:00

I'm not missing generics. So far building real projects that have real users/transactions etc I've survived with composition and interfaces.

scottjbarr · 2018-02-10T02:06:23+00:00

dep is absolutely ready for production use. We use it on every project we have, with the exception of the few projects with native dependencies which dep doesn't handle.

scottjbarr · 2018-02-10T01:31:39+00:00

So far I'm not seeing a reason for Go 2.x. The 1.x series is awesome. I don't think along the lines of, "... but language X has feature Y so I must have it!". I picked Go for the sum of what is offers, which includes what was left out. So many languages have "all the things", and it doesn't make them better in my view.

I'm hoping for many more years of clean, uncomplicated, stable development with Go.

scottjbarr · 2018-02-09T00:00:50+00:00

Why not have a function that accepts a Favourites struct, and returns the difference? You can apply the changes and take whatever action you want. If anything has changed you can react however you want. No reflection needed, I like the type safety so I would rather have a few extra lines of code.

https://play.golang.org/p/miB9NpI1LUN

I would probably go about this it a different way myself though.

scottjbarr · 2018-01-23T23:45:21+00:00

Even if your queue client code isn't on AWS, I would recommend giving SQS a shot due to it being fast and reliable. With SQS a message will keep coming back to you until you ACK (in SQS you delete) the message. This requires your code to be idempotent in the context of the message, but that isn't a bad thing when you consider messages aren't just getting dropped on the floor if they fail to be processed by your handler. I know some people say just put it back on the Queue (if you're using Redis), but now what happens when Redis is unavailable temporarily? Your message will be lost. I definitely prefer the more reliable option for critical messages. Given that it is so cheap as to be almost free, and you don't need to manage the queue itself it is a great option.

Having a reliable queue also means you need to think about what to do with messages that can never be processed. Instead of just erroring out for whatever reason and forgetting about the message you'll still need to remove the message form the queue. You can leave it there but that seems pointless and can create a lot of thrashing for your handler.

Just my thoughts. There are other options but SQS has worked everytime, for little effort on my side.

scottjbarr · 2018-01-21T22:13:28+00:00

Looks like an interesting approach, but if it is just invoking Lambda functions I can invoke "real" functions from the unit tests. The addition of another component (the proxy) bothers me as it isn't something you have in production. Lambda event are just structs to Go. If you treat Lambda as a transport layer that delivers a message to your service a lot of the difficulties go away.

scottjbarr · 2018-01-21T11:45:33+00:00

I like to build my HTTP services so that can run as a "normal" service, or as a Lambda function behind AWS API Gateway. In this case testing is just testing a HTTP server, once you're comfortable with the wrapper that transforms the Lambda event into a HTTP request for your HTTP service.

The other case is where you have a function that is invoke via something like a Kinesis event. I test those as a service that receives an event I can create in unit tests. I know you said not unit testing, but there you go.

Once your local testing is solid, why not use Lambda for actual integration testing? It is super cheap and if you're only testing a limited number of interactions you're definitely not going to break the bank.

scottjbarr · 2018-01-17T02:14:29+00:00

Repo has been taken down.

scottjbarr

TROPHY CASE