-
I can’t speak for the rest of the teams at work, only for my own team, which is somewhat unique to the company because our code actually interfaces with our customers, the various Monopolistic Phone Companies, in the call path of a phone call. With that out of the way …
Developer (me and two others) write the code. Bug fix, feature enhancement, new feature, what have you. Once we are happy, the ticket (Jira) is assigned to our QA engineer, who does testing in the DEV environment (programs generated by our build system Jenkins—ops can automatically push stuff from Jenkins to the various environments mentioned), Once that passes, it moves on to the QA environment and another round of testing. Once that passes, it moves on to STAGING for another round of testing. Once that passes, we then submit a request to our customer, the Monopolistic Phone Company stating our intent to upgrade our stuff. They have 10 business days to accept or reject the proposal. If they reject, we wait and try again later. If they accept, on the agreed upon day (actually, night), ops will push to PRODUCTION. During the push, the QA engineer and developer(s) in question will also be there (on the phone and via chat) to test and make sure things went okay in the deployment.
There have been two times when during the push to PRODUCTION, things weren’t working correctly, and I (the developer) called for a roll back, which is easy in our environment (both times dealt with parsing telephone numbers [1]).
The testing of our stuff about half automated. The “happy path” is automated, but the “less-so-happy-paths” aren’t, and they’re quite complex to set up (our business logic component makes queries to two different services, we need to handle the case when both time out, or one but not the other—that’s four test cases, only one (both reply in time) is easy to test (there’s a difference between the service being down, and its reply coming in too late)). As for writing the automated tests we do have, that has been my job (I started out as the QA engineer for the team in question, even before it was a team [2]). The QA engineer does write some code, but will come and ask me about the finer points of testing some of the scenarios.
Sadly, STAGING and PRODUCTION should match, but for our team, it doesn’t. And some stuff can’t be tested until it hits PRODUCTION, because how do you test an actual cell phone in a lab environment? Especially when your company can’t afford a lab environment like the Monopolistic Phone Company has?
[1] If you can avoid doing so, avoid it. I cannot. I need to parse numbers for the North American Numbering Plan, and just that is difficult enough. I’ve seen numbers that make me seriously question the competency of the Monopolistic Phone Company to manage their own phone networks.
[2] Long story.
-
Clients I work with uses a thing called femtocell to setup cell networks from one country on another, in order to run tests. It’s quite expensive, though (or so I hear), and they’re moving onto other alternatives as much as possible.
-
-
-
Painful.
-
So, I work on two projects at work. One is a agent, part of a distributed system, that runs in several servers and provides access to some hardware connected to said servers. We maintain some of those servers, others are run by users. The other project is a library, used by the first project.
The agent system is release once every sprint, and our sprints take 2 weeks. In the Tuesday of the second week, we ‘close’ the release: nothing merged after this will get in the release, unless it’s a bugfix. Then for the next 3 days, we run manual tests on the whole system (of which the agent is a part). If errors are found, we merge the fixes. We use a sort of trunk based development, so, if we find a bug, we’ll create a release branch and cherry-pick it there. Once we ran all tests, we manually generate a zip package (which involves creating a fresh clone, copying a bunch of files around, and zipping the resulting folder) and a) manually deploy it to the servers we maintain, and b) upload it to an internal confluence page.
It’s very manual and very error-prone. We’re finally automating some parts of it, but it’s not done yet. The system is written in python, so we could be a simple pip package, but for permission reasons (not everyone is allowed to run it), we’re not there yet.
The library is kinda worse. First, it has a binary dependency, that lives in separated repositories, so we have to make sure we keep the versions synced. It’s also a python project, but also not packaged as a pip package. The way it’s release is: We compile the binary dependency, copy it over to the development repo. We than commit and merge the release in the development branch. Then, we copy the changes, MANUALLY, to a “release” repository, commit it in there, and merge it. The users get the updates from the release repository, and we work in the development repository. I tried to sync the repositories history, to simplify this freaking mess, but there are manually applied changes in the release repository that make it impossible (or nearly) to just squash and push the changes from the development repo to the release repo.
I recently wrote a small makefile to automate some of this terrible process, and my plan is to bring all this crap together in a single repo, split the library into two parts, and package both of them as proper pip-installable packages, but we’re a fairly long way from that, yet.
Tell me that ain’t painful.
-
Oh, also important to note: the agent system has some automated tests, that are supposed to run for every pushed commit and give it a -1 code review if it fails. That’s broken, currently, and because our PO is a , we haven’t had time to fix it yet. When it used to run, it was a good thing, but we don’t have lots of coverage, and the main server (that controls all agent servers), has almost no automated tests, so, there’s that.
The library has some unit tests, but it’s a library to communicate with smartphones, so, there’s only so much test you can do without actually connecting it to a real phone and testing it. We do have a separated repo with integration tests that use real hardware, but it’s completely broken and I haven’t got time to fix it yet. So right now the reality is: I run the unit tests before a release, run a basic connection test, and hope for the best =/ Our release cycle is pretty tiny, one week, and we have release a worrying amount of bugs into production in the last months. I raised that with our manager and got the usual “Yeah, we should worry about that” response that will likely turn into no actual action.
-
Thanks for elaborating. I think that managers can be motivated by costs sometimes. If you add up the time it takes to do all the manual steps, say, over a month, then the effort required for automation might look more attractive. Maybe you could show that it will pay off within 6 months or a year.
-
-
-
Your comment doesn’t answer the OP’s questions and doesn’t contribute anything to the discussion. Please write something useful instead. I’m disappointed that several people thought this one-word comment should be upvoted.
-
-
It would be better if lobste.rs didn’t devolve into obvious one-word jokes. There’s already Reddit.
-
And as with all jokes, it has some reality to it =/
-
-
-
-
-
-
- commit and push changes on personal branch, tell someone ready for merge.
- any other team member reviews and merges into stable and pushes to the stable repo.
- CI runs
make deploywhich will run tests, builds and then deploys it.
Personal Projects:
-
make deploydoes the right thing.
We use Makefile as our entry point into our projects, make is everywhere, and it’s mature, well tested software, the warts are well known, etc.
make testwill just work, regardless of the language or tools actually used to run the tests, etc. i.e. for Rust code, we use cargo to run tests, for Python code we use pytest w/ hypothesis, but you don’t have to remember those details, you just remembermake test.-
Always had a prejudice with Make, wrote a makefile the other day, it changed my mind. I still find the syntax and documentation messy, but it’s good for what it’s intended for. I plan on spreading it’s use at work.
-
Good luck! I agree it’s not perfect, it definitely has warts, but it’s very mature software that’s not going away anytime soon. It will die about the time the C language dies, which won’t be in my lifetime.
Other build software, it’s anyone’s guess how long it will be maintained.
-
-
Roughly thousands of manhours of manual testing all over the world. Requires a few months and millions of dollars. Details vary depending on the customer.
For the developers there is continuous integration testing for each pull request done via x86 simulation and on target device. Code reviews for each pull request. Sometimes manual full system testing by developers but mostly by a special integration team.
I’m working for an automotive supplier so our processes are probably not applicable to you. The contrast might be interesting though. ;)
-
Work with an Android integrator, sounds remarkably similar. I develop tools to help people test the actual android devices, so I don’t work with that specific workflow, but the people that actually work on Android, it’s pretty similar.
-
-
Current job (small team):
- Commit and push changes
- Concourse CI picks those changes up and
- if they’re not tagged, it runs the unit tests and stops
- if they’re tagged, it runs the unit tests and continues
- It builds docker images and pushes them to ECR
- It deploys those images to ECS in the staging environment
- We monitor the changes in staging (metrics are scraped by Prometheus w/ graphing from Grafana)
- If everything looks good in staging we push a button in Concourse to send the images to ECS in the prod environment
Concourse build pipeline definition, tasks and scripts are defined in the repo and infra is managed with Terraform (which Concourse runs). It took me about three days to set everything up and it has been running smoothly ever since (~6 months).
To roll back, we just re-run older deployment jobs.
We don’t have a dedicated QA team. Everyone tests their own changes or asks someone else on the team for help and we have an extensive unit test suite.
Side projects (just me):
-
./scripts/deployruns tests and deploys either to GAE or Heroku and that’s it.
-
-
Oh, using the tags to decide whether to deploy or not is a niiiice idea, I’ll steal it.
-
-
Sounds interesting, might solve a problem I have at work, too bad it’s coupled to github =(
-
-
-
-
-
Anything self-hosted would be viable, but everything on git would be even better, although probably more complicated. We use gerrit at work (which sucks at several levels), and mostly anything third-party is very much disallowed. Maybe you could create an abstraction that would speak Github API to github and git protocol to other servers where this would work?
The other possibility could be a sort of optional backend/proxy, so, if the git server doesn’t have CORS, you could spin that optional server.
-
After thinking about it some more, there’s a lot that GitHub offers that I would have to reimplement myself. Authentication, for one thing. If it was used in a stand-alone mode in enterprise, some kind of authentication would be still needed. People would probably want SSO. Then there are notifications. GitHub sends you an email when you are mentioned in a bug. I would have to somehow interact with company’s mail server. And so on. This is my hobby project and I don’t really have time to go into that amount of complexity.
-
Sure, makes sense. It’s still a cool project, nonetheless, so, congrats =)
-
-
-
-
-
-
-
-
-
-
I never used Erlang, nor have I used any of these modern statically typed languages. However, it sounds weird to me to say that because I can’t assert that a function has no side effects, or because I don’t have type information about it, I can’t combine/reuse them. People combine functions in Python all the time, there are whole frameworks built on top of decorators, which are basically high order functions.
Granted, lots of arguments can be made that this is more fragile or less maintainable than using a statically typed language, but it doesn’t stop people from reusing code in these languages, nor does it stop them from shipping some pretty big systems in it. All in all, it seems like a non-sequitur to say that lacking type information or not being side-effect free makes composability impossible.
And secondly, even if it was impossible to compose functions without static type information, not all actor systems have to be dynamic. Pony comes to mind as a actor-based language with static typing, and there’s that framework in Scala that I forget the name and can’t be bothered to google right now.
-
That was pretty interesting, didn’t know about the object shape thing.
-
- 06:30 - 07:00 -> Alarm goes off, I snooze it, firmly beliving it will be only for a couple of minutes
- 08:00 - 09:00 -> I finally wake up, half-desperate that I’m missing some meeting, half pissed of at myself for being late AGAIN
On a good day:
- 09:00 - 10:00 -> Breakfast, shower, leave to work (by bus)
On a regular/bad day (those are more frequent):
-
09:00 - 10:00 -> Pooping and farting and waiting to see if I don’t have to poop or fart again (I have Crohn’s disease, and it’s been acting up lately)
-
10:00 - 11:00 - > Breakfast, shower, being angry at the uber driver for taking too long to arrive
-
10:00 - 11:00 -> Arrive at work, check email/chat, do quick code reviews and answer emails if needed
-
12:30 - 13:30 -> Lunch.
-
13:30 - 15:00 -> Trying to figure out if there’s anything productive at all I can do until 15:00
-
15:00 - 15:20 -> Daily sync, currently at this completely stupid time because of freaking timezones
-
15:30 - 16:00 -> Complaining about whatever happened in the daily sync meeting
-
16:00 - 18:30 -> Trying to get some work done: discussing design/architecture stuff, sending emails to gather info, following bad manual processes because I don’t have time to automate them right now, and, if the gods smile upon me, doing some coding or other programming related activities that don’t make me wanna kill myself
-
18:30 - 19:30 -> Give up work because it’s late, try to organize list of things to do tomorrow, procrastinate
-
19:30 - 20:30 -> Go home
-
20:30 - 23:30 -> Hang around thinking that I should be doing something productive instead of just browsing social media and watching youtube/netflix
-
23:30 - 2:00 -> Eat, watch some more youtube/netflix, go to sleep.
-
Tarball of all the videos: https://timetoplatypus.com/static/das.tar.gz
-
This is literally how the guy makes a living, so, maybe don’t do that?
-
I took it down.
-
Very considerate of you! :)
-
Ya I didn’t intend to upset anyone, it was purely a convenience thing.
-
-
-
“First, everything is free all week”
He’s encouraging people to grab his videos by giving everything away for free. All he required was a login which may have monetary value later that timetoplaytypus’s share negates. It’s possible, though, he thinks they can only grab a small amount of videos with some portion of people paying for the rest after deal expires. That’s on top of new, recurring revenue from it on future videos. Maybe this hurts him on at least gap between what he though could be shared and what would be. In that case, he’d have made a gamble that may or may not pay off vs offering a limited number of videos with a clear prohibition on sharing them.
On ethical side focusing on results, I don’t think there’s a huge difference of someone here sharing his videos all at once in convenient form for free vs him saying grab as many as you want after you log in for free. Given freeloading users vs type and number that would pay him, I don’t think he’d have many losses in that scenario if any at all. The kind of people that would pay him would probably mostly still pay him. Hopefully, no effect.
-
He’s encouraging people to take a free look at his work and see if they think it would be worth for them to pay for more of it in the future. Shitty people that don’t care about anything else but themselves might interpret this offer as an invitation to take advantage of someone’s work, and even actively undermine this someone’s livelihood. I think these people are at least half of what is wrong with the word and they should all go live in a cave and never interact with anyone else ever again.
-
I hear you. It’s a sensible perspective. I prefer he keeps getting paid for doing good work, too. I also agree that this should be the norm instead of pervasive parasiting.
-
I think you see the situation a bit radically.
On one hand when someone publishes a free software and people use it for their benefit without any pay then they are shitty? When someone decides to publishing something for free, then the factor that some people may not pay for it must be calculated into that decision.
I believe that the ad-supported word is a bigger threat, as makes the feeling that stuff are for free a norm.
-
Neither of those examples apply. OP is publishing something for free for a LIMITED amount of time, with the very obvious intention of giving people a preview of his product. Free software and free content are very different propositions.
-
I still think that the possibility had to be factored into this offer, and it likely was. The style and language are still harsher than I think the situation justifies.
-
Fortunately, I don’t care what you think.
-
-
That is your right to do so.
-
-
-
-
-
-
-
let’s be real here. the first thing i thought of when i saw this was “can i write a script to download everything before the deadline” and im pretty sure 99% of people here thought something along that line.
given the target audience of his screencasts, you kinda have to expect this.
-
Everybody thinks stupid thoughts, but not everyone acts on it. And since we’re a big part of Gary’s target audience, wouldn’t it be nice, if it turns out he overestimated the amount of dicks among us? By the way, first thing in my head also was “Hmm, can I download it?”, but then I remember the guy has to eat.
-
The swearing you demonstrate in your comments is disturbing. I hope it will not become the norm in the comments section.
I believe you could also communicate your point very well without using words like “shitty people” and “dicks”.
-
-
-
-
I come to comment on this because I remembered this tweet he posted on the matter, a while ago: https://twitter.com/garybernhardt/status/870721629440983041
I’m glad it’s been taken down already, I think its just fair to the author’s work.
-
-
-
Any endpoint on my site that doesn’t exist returns HTTP 451
Edit: for example, https://timetoplatypus.com/abc
-
-
Nah, it’s just a mistake on my part. I’ll get around to fixing it…eventually
-
-
-
-
-
tonnydourado
6 months ago
|
link
| on:
Unfortunately, StackOverflow is a difficult-to-avoid site nowadays…
Effectively, every 10th answer or question just gets wiped out
That’s the thing that most caught my attention. I mean, that seems like a good rate, actually. About 70% of everything I do or say is garbage, I dream about having only 10% of it being thrown away.
That being said, I do agree that’s weird that you can’t see your own deleted stuff. Should be possible, if only so you could post if somewhere else, if it’s not fit for stackoverflow, which has a admittedly quite narrow profile for content.
-
My two cents regarding my personal projects…
When I was working on the MATHC
1.x.x, I was using SemVer, which has a concept of not breaking backwards compatibility while in that major version, possible of adding features in each minor version (x.MINOR.x), and having the patch version (x.x.PATCH) for fixes.The SemVer process is very inorganic, and the development was often affected because of SemVer rules. This was the same thing I noticed when contributing on OSS projects of others. Having a critical design flaw and you just made a patch that will fix that? You will have to wait until the next major version, because it breaks backwards compatibility.
When I released MATHC 2, I switched to CalVer, and the scheme was
YYYY.MM.DD.MICRO. The version was actually MATHC2018.08.02.0. It’s a pretty straight forward scheme, as the version is just the dates. I added aMICROfor reserved use when I had to publish two versions on the same day, in case I noticed a bug right after the previous release. I always try to keep backwards compatibility, but the development of my project is not affected by it. If I have to break backward compatibility, then I will break it, and I will mention in the release notes. The versioning scheme doesn’t rule over the development process, it’s just a reflection of it. Very simple.Regarding testing, I had test units during the first major version, but it was a lot of work for only one person to take care of, and it was hardly ever useful. I removed the test unit in the newer versions and I rely on the feedback of users to identify hidden bugs. The good thing about personal OSS projects is that you can easily make changes to prioritize your mental health over the project :)
We use calver at work as well, and if for nothing else, just not having discussions of what is a major, a minor or a patch release is SUCH a good thing.
I know, right? I wish other projects followed this scheme. After some time using CalVer, I’m starting to believe that SemVer is (to some extent) holding back the quality of software.
I mean, IF we could automatically determine whether a release is major, minor or patch by checking the public APIs, then that would be great, but there’s no way to do it reliably in most languages. Without this kind of tooling, it might make sense to use semver for libraries, but for systems that are used by humans, not really.