261 karma · joined January 1, 2021
codersnow337(at)gmail.com
If the only goal is to prevent forest fires, then in theory you could just send a hoard of people in to gather up all the dead wood at the end of each season, pile it up and have some nice fall bonfires, which might be fun. The main issue is the terrain harsh and would be very time-consuming.
Thank you for pointing this out. When I was looking to install caddy, I was specifically looking for something without using docker since my VPS is 1g / 1cpu and that is what I based my comment off. When was reading the sidekick docs seemed by running one command that it would first install sidekick and then install the cert/app all with one docker file but now I am not even sure about that.
Appreciate you pointing that out, now I am back into analysis paralysis on which one I should use
Like others have said, just some random on the internet, but at a minimum seriously find a wordsmith to update that resume and some recruiter will be contacting you. Also, more is not better no need to list the Test Tech or Mac Repair since other jobs overlap with those years and makes it seem like you were only part time. Everyone fibs a little bit no one is going to ask if you were part time or full time on a job from 20 years ago. Also, if you have self-employed listed make sure you have the tax# and LLC cert from the state as they are going to want to see that as proof to count as relevant experience.
I know you did not ask for my advice, but after reading your reply got me curious about why so gloom. As programmers we need to market ourselves and fake it till, we make it.
Ctrl F - Code Reasoning:
Sounds like its a no go anyway, but just in case this is not the one you already found.
https://cheerpj.com/licensing/
The X version seems to be minified CDN hosted .js file but no other info about usage. The only comment in the file indicates that its some sort of C/C++ file presumable ported over to JS
/Compiled using Cheerp (R) by Leaning Technologies Ltd/
Licensing
Cheerp is free open-source software, actively developed and maintained by Leaning Technologies. Commercial support, feature fast tracking, sponsored development and consulting packages are available for Enterprise customers.
When the tests fail, or the code quality goes down, the deployment fails. I would rather have DEV broken than PROD. Not sure how going directly to PROD would make anything better in this scenario. That is what Integration is for never broken always ready for promotion to prod. Plus a few broken dependencies means ‘yellow’ === impairment not unusable. If the app is unusable for any one dependency that is another issue.
Mocking data when you are ahead of another team is always the reality…
Guess that is why Netfix is so Glitchy every other day j/k.
I should have kept that last sentence out but I will not edit it now as I asked….
Long lived branches are a problem if you are doing hot fixes to prod. The goal is the process avoids hot fixes and critical bugs.
Some industries would not allow software to be released more than every few months. SQA needs to sign off. Users need to UAT. 2-week notice, 15-minute notice to log off. Downtime needs to be communicated to multiple time zones. Software versions need to be auditable for regulatory.
The only point I was trying to make is ‘publishing’ multiple times per day with a team of developers requires ‘devops’ and that release does not always mean to prod. The same setup for releasing to prod multiple times per day is the same as releasing to develop multiple times per day.
Long live DevOps
When I do a commit prettier is run. When I PR into develop other dev’s review the code. When its approved and completed a build is run (including all tests and sent to Veracode and SonarQube for analysis). The build is deployed to the development container where the developers can smoke test and then when SQA is ready promote to Integration for real testing. Fail fast! If the tests fail, we can fix them. If code quality goes down, we can fail the gate === no deployment. Without DevOps and CI/CD these steps get skipped.
Not sure where the idea that software is released to production multiple times per ever came from. Yes, the develop branch should in theory be ready to be promoted at any time but we know that is not reality.
PS – thanks for the reminder of this one, was searching to post the exact same comment….
The best one I have is letting others fail, they are going to anyway. When put on a new project with a new team who has been working together for a while, they are NOT going to listen to you no matter how much experience you have even if you consider yourself a SME. I often find myself fighting against what I think is the correct solution as the team will want to do the opposite of the ‘new guys’ suggestions…
Thank you for the information as I always love learning more from the comments than the articles.