I don’t know a good option. Currently I own a 15” mbp 32G, best compromise I could find when upgrading from my 2015 13” (I strongly considered a dell xps 13” at the time but the build quality and trackpad were a no go for me). If I were to upgrade I’d reluctantly get a 16” 64G mbpro. I keep sacrificing on size in exchange for build quality and specs.
I founded the first web based background screening company in 1996 and I am back in the industry today, here is what I would do:
tldr; if it is sealed, do not worry about it. If not, be upfront as soon as possible.
Call the court clerk in the county the record is sealed in and confirm the record is sealed; If so, when a court researcher searches for the record, it will not appear and not be reported by the CRA (Consumer Reporting Agency is the technical term for a background screening company).
If you have never lived or worked in this county, it may never be searched.
If somehow the county reports the record and it is sealed, and the employer does not hire you because of the record, the employer has to do what is called the adverse action process, which gives you an opportunity to dispute the information before taking final action. During this time, you can have the CRA remove the record.
It’s interesting that you can call the clerk to determine that a record is sealed - it sounds like a potential vulnerability where sealed records can be exposed by social engineering.
As a disclaimer every court in the nation can operate differently although they're all kinda similar.
Adoption records in the USA were sealed last century. Seems to be a temporary fad that's going away. Maybe it was a Spanish Flu thing.
Anyway if you try to pull my long deceased great-great-uncle's records for genealogy, they simply give you a negative result to the query, although "everyone knows" he was adopted.
Elixir and the ErlangVM are a bit too exotic for this project and me, but it does sound interesting. I will probably try it out for something simpler in the future. Thanks.
But yea that's indeed what I should have done in my example if I wanted the component to be reactive, as you can see that's even more verbose and still doesn't take care of props.
And, isn't it likely this will be easier to support with Svelte eventually? My reasoning is that you just need to add a little syntactic sugar to the language and the compiler can add whatever code is necessary? With a runtime like React and Vue, it seems much harder to add in.
It's think it's likely the two issues I highlighted will eventually have syntactic sugar, I never wrote a transpiler but it doesn't seem that hard to support. It doesn't appear to be a priority though.
> With a runtime like React and Vue, it seems much harder to add in.
As a rule of thumb, it's almost always easier to add things at runtime than at compile time. That's why it took us so long to get Rust.
I've been looking for a something to do virtual cards for single-use payments and/or assign a virtual card to a vendor, preferably with webhook style notifications posting back to our servers with charge activity.
You can easily create a virtual card for vendors and set low limits! But we don't support webhooks yet, but good idea. We don't believe in single-use payments because it's a pain to manage multiple card number, but we soon we'll have the ability to restrict a card to a vendor/category so you can just add specific payment abilities to the same card number.
A filesystem snapshot is only reliable if you stop the database to do it, or if there is some sort of cooperation between the database and the tool that triggers the FS snapshot creation.
File system and LVM snapshots are atomic, so if you cannot get a working database from that your database won't survive a power failure either. You can also do a file system backup of PostgreSQL without atomic snapshots but then you will need to inform PostgreSQL of the backup and then copy files in the right order. The pg_basebackup tool and various third party tools handle this for you.
Our market (Sacramento, CA) is so hungry for senior engineers (for web or mobile), I'd wager max 2 weeks to be back in the saddle. But I doubt HPE has much talent for web-stacks, likely Microsoft/.Net and SAP experience which I can agree with your statement.
We just interviewed a PM from HPE and to our surprise, he makes ~$180k a year. We hired an awesome candidate for $80k.
And no, finding a job in 2 weeks is not realistically obtainable for a senior engineer. Try 6 months to a year. This whole 'developer shortage' BS I keep hearing needs to stop.
And besides, most employers' hiring timelines (from first contact to first day on the job) are longer than 2 weeks.
$80k is what we paid for a PM, not a senior engineers. We pay our seniors $120-$250 depending on how their domain experience maps to ours, and if you want to live and work in the Sacramento Area I can have you interviewed, vetted and on-boarded in less than a week. Being in Sacramento, we have lost talent to the Bay Area for top candidates coming into the state that want to work for a more known entity and a have a larger network work within.
No BS or bad vibes; Just real peeps writing code and having fun doing it and always looking to add great people to the team because the demand is high and experienced talent is in short supply.
2 weeks for a job is pretty tough but not unachievable. I'm not the best engineer on the planet, however I've experienced probably a month into a job search there are some solid offers on the table. I'd go insane looking for a job for 6 months, at month 2 I'd feel there was definitely something extremely wrong.
We do this and have great success with a small SMS/Email application doing ~2mil jobs a day (mostly over a 6hour peak period).
Except, we use postresql's LISTEN/NOTIFY which amazingly is also transaction aware (NOTIFY does not happen until the transaction is committed, and even more amazingly, sorta de-dupes itself!) to move the jobs from the database to the message queue.
This way we never lock the queue table. We run a simple go program on the postgresql server that LISTEN's, queries, pushes to REDIS and then deletes with a .25 second delay so we group the IO instead of processing each row individually.
This also allowed us to create jobs via INSERT FROM SELECT, which is awesome when your creating 50k jobs at a time.
We are sharing your sentiment that a lot of our user-facing errors could be limited by moving away from weak typing (current stack is Ruby). In hindsight, did Go and protobuf prove well, we are evaluating Go and possible Elixir as a sweet spot between static and dynamic typing.
Yes. I would always use gRPC-gateway in the future. It's an amazing library. Check out the `protobuf` folder - we basically defined the whole api there in a language-agnostic way. For client libraries, you can autogenerate gRPC definitions quickly. For servers, gRPC-gateway provides a Swagger definition that meant that we always had 100% up to date API docs that include a Postman-style way to execute calls. The auto-generated API docs sped up front-end development so much.
I think that access to the docs requires logging in, so here are some screenshots: http://imgur.com/a/R0AvB
Jason Chen is using Elixer/Phoenix for his new project, by the way, and thinks that it's the future for Rails developers.
I'm considering moving from a macbook pro to the blade and adding the core to get a beefed up desktop experience with the ability to unplug and take work anywhere it needs to go. I'm assuming I would need to stay in windows land with linux via Hyper-V. Besides iMessage, all my apps run on linux (more-so) or windows (less-so). Any thoughts?
The only loss i've felt so far is my documents that were written / design in pages & keynote. Still have a older mac around to handle them. Otherwise i'm back to Windows 10 fT with the Hyper-V bash and docker. So far so good (going on a month now).
