rgharris

Error handling in Go is simple and verbose at the same time. Working in it alongside Python and JavaScript makes me rethink a lot of patterns I’m accustomed to - it’s a nice exercise. Though of course the use cases often vary significantly between the 3 languages so it is tough to even compare.

Great point. With this change the pricing tiers make perfect sense for companies/projects at any stage:

- MVP (was Hobby)

- Startup

- Business

- Enterprise

If you aim for this point alone you're headed in the right direction:

Think like an adversary, but be nice about it. Try to “catch” authors taking shortcuts or missing cases by coming up with problematic configurations/input data that breaks their code.

The article is a great overview and goes into just enough detail - here are a couple more good points:

- Comments: concise, friendly, actionable

- Think about how you would have solved the problem. If it’s different, why is that? Does your code handle more (edge) cases? Is it shorter/easier/cleaner/faster/safer yet functionally equivalent? Is there some underlying pattern you spotted that isn’t captured by the current code?

I just did this for a controller that is hosted on a VM (via the new controller UI), I went through a couple of additional steps.

1. Disable "Enable Remote Access"

2. Setup SMTP (since disabling remote access stops routing emails through Ubiquiti's backend)

3. Create a new admin not tied to a cloud Ubiquiti account (via "Administrators")

4. Disable "Sync Local Admin with Ubiquiti SSO" (the older UI says "Enable Local Login with UBNT Account")

5. Delete the old admin account

Steps 3 and 5 may not really be necessary, but I did to be safe.

Agree on the storage point, I used their Redis and Postgres options for a few years with no real issues. Everything was seamless, even maintenance. The only complaint I could have would be cost, but that is expected.

Also, using S3 is simple and shouldn't incur much cost due to running in the same AWS region.

Heroku CI, Pipelines, and Review Apps made for an awesome continuous deployment setup for me in the past.

Easy promotion of builds to staging/production after your tests pass and apps created automatically per pull request for testing in an environment just like all of your other environments.

I have fairly large hands and could hit all of the thumb keys. But I only use 2 so that I don’t have any reach or large movements when typing. I agree that it depends on hand size and your preference. Regardless, it has been an awesome keyboard for me due to customizing layout/layers.

I’m in the same situation. I have large hands but only use 2 thumb buttons per side and also use layers to avoid the top row of the keyboard altogether. I love the Ergodox but prefer to limit my reach for better ergonomics.

Ionic Appflow is a very different platform but it is interesting to have products with the exact same name (except the capitalization of "F") in the software/platform world.

https://ionicframework.com/appflow

All good points. Roth vs traditional can be complicated when you think about the long term possibilities (change in tax rates, early withdrawal, lower/higher income in the future, etc.) but definitely max out Roth/Traditional/Backdoor Roth IRA if at all possible after getting max employer 401k match. I like the idea of diversifying with pre and post tax retirement options to an extent. Backdoor Roth IRA is useful for high earners that don't qualify for a Roth IRA or Traditional IRA deduction.

Lots of reading (books, blogs, etc.) has been helpful for me the past few years and it seems like I pickup new things all the time. A few things I use/reference:

- YNAB (You Need A Budget) - budgeting/tracking app, plus lots of great content on how to use the software and generally manage your budget/expenses

- /r/personalfinance subreddit - checkout their wiki [1] and flowchart [2] in particular for a really helpful overview

- For investments I use spreadsheets to track allocation, targets, etc.

- Bogleheads wiki - investing, heavy on index funds, low fees, etc.

- Whitecoat investor - a lot of good content, mostly aimed at high income earners plus some content specific to medical doctors [3]

- A variety of books - there are a lot of good ones out there

1. https://www.reddit.com/r/personalfinance/wiki/commontopics

2. https://www.reddit.com/r/personalfinance/wiki/commontopics#w...

3. https://www.whitecoatinvestor.com/new-to-the-blog-start-here...

I agree, end-to-end tests have been really valuable for catching SQL issues in my experience.

> Identify unsafe queries that could potentially lead to SQL injections

This feature seems like a perfect use case for static analysis and would be a great tool in addition to automated tests.

Awesome, I think your plans on feature development make a lot of sense. Hopefully I’ll have some time to try it out in a real project before long!

I really like the sql() helpers and the naming of the unsafe() method. The file query helper is great - I've moved to using external query files for everything in a current project.

I've used pg-promise a lot and this seems to cover a good bit of the core functionality and could be extended pretty well in a project. Do you plan to continue building out features or are you looking to keep this as lean as possible long term?

Also, does sql.file() support named parameters or just indexed parameters (like $1)?

I think the article and you are correct - the article is worded a little oddly though and ignores the fact that in Postgres 12 CTEs that are referenced multiple times are MATERIALIZED by default.

Before Postgres 12 CTEs were always materialized so you did not get any query optimization benefits of CTEs acting like inline subqueries.

After Postgres 12 all CTEs default to NOT MATERIALIZED if only referenced once or MATERIALIZED if referenced more than once. You can override via MATERIALIZED or NOT MATERIALIZED when defining the CTE.

Their example is showing that you can let Postgres (before 12) optimize a CTE for you by writing it as an inline subquery instead of a CTE:

  SELECT *
  FROM (
    SELECT *
    FROM sale
  ) AS inlined
  WHERE created_by_id = 1

But with Postgres 12 their "don't" example would result in an index scan without refactoring to the "do" example. Basically their advice on do vs don't applies to before Postgres 12.

https://www.postgresql.org/docs/12/queries-with.html is pretty thorough on this

Triggers definitely have their place and can be very useful. But they can pretty quickly grow out of control leading to lots of side effects making it difficult to maintain and possibly leading to performance issues. I think twice before adding a trigger to consider if it is really necessary because using triggers as your first tool to solve problems can lead to a lot of complexity.

I like the author's point about this:

> The trigger function itself was also written in the “schema.sql” file which meant that everything was clear and documented along with the other relevant schema information, thus easier to track and manage.

In my experience, in most cases the application doing the insert/update/delete is the best place to handle most side effects. That may be an on-demand API, a scheduled/queued job, etc. I've found triggers to be helpful and simple for audit and history tracking. There are definitely plenty of cases where triggers are useful and it probably depends a lot on your architecture.

This might be common knowledge but I just recently realized that several states are already trying to move to daylight savings permanently.

From https://www.vox.com/science-and-health/2019/10/28/20931998/d...

> Arkansas, too, passed a bill to make daylight saving time permanent, but it included the condition that the changes wouldn’t go into effect until its bordering states changed their clocks permanently too. Other states that have approved legislation to enact year-long daylight saving time include Washington, Tennessee, Oregon, Nevada, and Alabama. But none of the changes can go into effect without approval from the federal government.

It looks like the FBI has contacted Vice about the article.

> Update 11/1/19: The morning after this article was published, the FBI contacted VICE about the claims made above.

Really excited to see this. We have an Ionic Angular app that is running in production and being actively developed.

We probably won't get the chance to use Ionic React soon but really hoping this gets more people excited about Ionic. Being able to deploy to iOS, Android, and web with a single codebase is incredible for starting with a MVP and transforming it into a great product.

Until now Ionic has been mobile first. But they announced earlier this year [1] that they are working towards better desktop support. So I'm not sure it would be the best choice if you need a mature framework for desktop web apps right now and don't need hybrid/native mobile apps.

We're currently adding desktop support to our existing Ionic app that has been mobile only so far so we are banking on being able to work around that and Ionic adding better desktop support over time.

[1] https://ionicframework.com/blog/ionic-4-roadmap-new-features...

App Flow generally works really well for native app builds for us.

- Cordova plugins can be a pain - we have had to do a lot of research in Github issues/source code and in one case built our own plugin. We also have a few custom build scripts. Other than that things have worked pretty well for us.

- Automatic submission to app stores will be great since we have to spend a good bit of time doing that manually and we currently rely on TestFlight/Play beta testing rather than Ionic Deploy.

On desktop I saw it under Settings & Privacy -> Two-step Verification after clicking "Change verification method" (previously had SMS setup).

Here is a direct link: https://www.linkedin.com/psettings/two-step-verification

Your comment prompted me to check my LinkedIn 2FA and it turns out that they now support TOTP apps (they list Authenticator App as the option). I believe it is very new though.

Clutch! | Software Engineer | Birmingham, AL or remote | Full-Time | Remote | $65k-$95k + benefits | https://careers.imclutch.com

Clutch! is a game day parking marketplace enabling sports fan to rent privately held spaces. We plan to expand our platform over time to help fans get their gameday back in more ways than just parking!

We're looking for a full stack engineer who will work on our Ionic application (Angular/Typescript), Node API, and Postgres database. Our headquarters are in Birmingham, AL but our engineering team is remote first so you are welcome to work remotely (US only). We expect a lot of growth in our platform's usage this next year and are looking for another engineer to help us grow the product!

Generous health/dental benefits. Unlimited vacation policy.

Apply at https://careers.imclutch.com and mention HN in the extra information question in the application.