I'm surprised no one has mentioned using a teleprompter yet. You can pick one up for around $100 and when combined with a little 7" monitor (another $100) attached to your computer, creates a nice setup for zoom calls where you can look directly at your partner. Also doubles as a great talking head setup for video production.
I got a teleprompter when Covid hit. I do a lot of training and I use it mostly for "looking into the eyes" of my students.
I have a twitter thread describing my setup. [0]
Were I to do it again, I would get a slightly larger monitor for it. I don't know if it is causation or just correlation (I'm getting old) but my eyes have gotten a bit worse in the past bit.
Do either of you have a shot of what this looks like in practice? Google Images isn't giving me much. Specifically what the Zoom or Meet looks like from your perspective.
>I'm surprised no one has mentioned using a teleprompter yet. You can pick one up for around $100 and when combined with a little 7" monitor (another $100) attached to your computer, creates a nice setup for zoom calls where you can look directly at your partner. Also doubles as a great talking head setup for video production.
For anyone else confused about what a teleprompter adds here, it's that the two-way mirror lets you put a webcam 'behind' the virtual reflected screen, so it can be perfectly centered in the screen.
Though this just makes me want to tape or suspend a webcam to the middle of a regular monitor, so it could show actual size human faces.
The Youtube channel DIY Perks has a video making essentially a homemade teleprompter mod for a laptop with very cheap materials.[1]
I've thought about getting a proper teleprompter but my issue there would be screen space and lighting. Has this worked well with a decently inexpensive webcam or do you use a full-on streaming/production type camera setup?
I haven't tried using the teleprompter with a webcam, but I don't see why it wouldn't work. I use a Sony a6600 myself, with a Sigma 16mm/f1.4 prime lense.
Regardless, I recommend capturing in 4k, and running that through OBS so you can zoom/crop the image for ideal framing, optional of course.
I use the Caddie Buddy one [1], which is a bit more robust for bigger cameras. There are other options where you can use your phone or something, but I prefer using a mirrorless and a good sized monitor.
Oh my! A teleprompter for less than $200! I haven't kept up with this market, but that's so amazingly affordable. I've long switched to tablet for the text, but this is easily 5x cheaper than what I still use from a purchase back when dinosaurs roamed the earth. I'm guessing that mine is 5x heavier too. However, it is one of those things that once you have it, you don't need a new one so I've just never looked to see what is cheaper today
I recently did an interview on this topic [1] and I was surprised to hear the designer say, "If the developer tells me to design whatever and they'll build it, that is a huge fail". I kinda assumed designers were in their own world where we (developers) met at the DMZ, but his point is we are all part of the same team. The more I thought about it, the more sense it made.
That hardline hand-off from design to developer is only desired by arrogance (arrogant designers or arrogant developers). It should be obvious on the face of it that good design is about compromises between perhaps pure goals and what's attainable with the tech you have AND what's attainable with the product team you have.
Ditto for hardline requirements from project management. It's either a CYOA strategy or a holier-than-thou mentality.
Well said. Funny we realized long ago that you can't just have a backend team build an API then throw that the wall to a frontend team to use it, yet somehow, we often try to do that with design. To achieve what you describe takes more than a conversation, but a healthy and active relationship.
Some of the moments I enjoy the most are where I sit in a room with product and design for an hour and we riff on a design. The feedback loops between disciplines are where the magic happens and talking through things in person usually results in a lot of improvement fast.
Exactly! Faster cycles means less waste and more productivity, not to mention better solutions and happier team members. It takes work for sure to build those relationships, but everyone is better off for them.
When I worked at Atlassian, we had this issue as well, given all the many services that were deployed for products. A few of us left and created Sleuth [1] to solve it for Atlassian and folks like you. Sleuth helps you know what is deployed, its health, and helps with workflow automation. It also tracks the DORA metrics so you know how healthy a service release processes is.
I built exactly this in my Manim-based library, code-video-generator [1] (via the code-video-generator command and the --slides flag). It basically turns any Manim scene.wait() call into a pause that I can then advance with a clicker. I used it for this video [2], where I was recording in front of a green screen, but wanted the exact control when the animation continued. code-video-generator played the video fullscreen, which I then captured via obs [3] and used the obs display as a monitor to see if I was pointing at the right spot. Was a bit tricky to get all set up but worked pretty well.
Related, if you want to create a code walkthrough video, I wrote code-video-generator [1]
It uses Manim [2], an animation library commonly used by Math teachers, and adapted it to code walkthroughs. Just comment code as you do and it generates a video for it. I've been using it to generate visuals for youtube videos [3] with some success.
The library should work with a few other languages like Java, JavaScript, and C++. If you want to add another one, take a look at comment_parser.py as it is pretty simple.
My team recently put in automation so that we use CircleCI for the staging deployment, have it wait for manual approval, then deploy to production. However, we can also give the Slack staging deployment message a +1 reaction, which will automatically approve the production deployment for CircleCI. This way, we get an easy dev UX but all the CI features of CircleCI.
As my startup [1] is in the domain of CI/CD, I've been doing a bunch of customer development interviews to better understand how teams deliver software. I was also surprised how few teams use full Continuous Delivery, even at cutting edge tech companies. It is indeed often used by small teams, even within large companies, where they deliver internal backend services.
The most common seems to be auto-deployed to staging or a dev environment, with some sort of daily or weekly process for promoting to production. One company built a Slack-based approval process using +1 or -1 reactions, and another has a zoom meeting where every author has to attend and is walked through a checklist before the release is approved.
My team also had a manual approval step to production, which theoretically meant the dev would check logs, dashboards, and alerts before approving, but in practice both with us and teams I talked to, that is followed about 50%-80% of the time.
What we built into our product, Sleuth [1], is a way to automatically promote staging releases when the staging release was determined to be healthy and soaked for a minimum amount of time. This allows the 80% case to simply flow through to prod without developer babysitting, whereas we can easily interrupt the process with a -1 reaction in Slack if it needs more manual testing. I think this is the ideal - the common case is the code flows but you still have an easy way to interrupt the process when the change needs it.
All those years it has been on focus, I still don't understand what problem CD is expected to solve.
Yes, there is value on CI, and there is plenty of value on very low effort deployment. But, except from a large downwards risk, what does automatic deployment bring in exactly?
To me, the main value of CD is ownership. The developer can own a change from beginning to end, and most importantly, its impact on production. That feedback loop creates better future changes and a better developer.
Automatic deployment takes it to the next level where it becomes so easy to deploy that the dev starts fixing things they would have previously ignored because it was too painful, annoying, or time consuming to deploy before. A typo here, a refactoring there, and now they can fix, push, and go back to what they were doing within minutes, but do so with the confidence they won't break things. It is kinda like the difference from when CI takes 3 minutes to 10 minutes. It isn't much but that longer time means you alt-tab over to reddit or whatever, forget what you are doing, and now that task takes orders of magnitude more of wall clock time.
Ok, I was not explicit enough on my question. The benefit of low effort deployments is very visible.
What benefit does have a computer deciding that a version of the software is ready to deploy instead of the developer pressing a button when he thinks the software is ready to deploy?
Right, got it. I think it is the lag time involved in the pipeline. Once a developer clicks merge, CI has to run, an artifact has to be created and uploaded, then usually a deployment to dev or staging is kicked off. That takes somewhere between 5 minutes and 2 hours in my research. Then, once done, the dev can click a button to push to prod, though often that is just to a canary, so another 5-30 minutes, then repeated for other prod environments. That whole process takes a lot of babysitting, and realistically, the dev has started on another task and forgot about it, making it take even longer.
By making it automated, the dev can immediately start on a new task and the deployment can go out quicker, meaning the next dev can start on their deployment. Therefore, I see it as helping preventing costly context switching and therefore, improving efficiency.
Yet, it goes completely against my experience, so you've left me wondering what creates that difference and suspect it comes from organizational differences.
You certainly considered no post-deploy activity. That should have been obvious from the beginning, but I just didn't think of it. I suspect the post-deploy activities I'm used to go to the role of a product manager, and you are assuming a more jira-oriented environment than I was.
You are probably assuming larger software blocks than I am. I should have imagined that too, because I have a tendency of breaking software in many more independent pieces than it's usual, and of imposing that on my environment everywhere I go. I am used to people having something to do on a different project than the one they started a CI, so they can start right away, and come back after the CI is complete, so there is no wait. And there is no "next dev" waiting, because he is working on a different project too.
Also, having a different project to work on during CI means a major context switch if people need to fix anything on the previous change they made.
So, with that said, I can now imagine what kind of environment CD makes sense. It's somewhere with a small number of projects and a large team of developers (or, any place with a high developers/projects ratio). It's the kind of place where would be hard to coordinate a release if it was manual too.
Video creation and editing [1]. I used to speak at tech conferences but after taking a long break, I wanted to get back into some form of instructional content. My kids are obsessed with YouTube, and I started a new startup, so I figured I'd give it a go. As for how I learned, well, doing it, and of course, watching YouTube videos.
