Same here. But for the time being, I can just click away the modal (don't click any of the buttons) and the video starts anyway. I assume that will change soon.
In the video that shows the stolen tools in the warehouse, there are hardly any Ryobi tools (HomeDepot's cheap tool brand). This is in stark contrast to many of the recent woodworking videos on Youtube that feature craftspeople using Ryobi tools (without explicitly mentioning an HD sponsorship). The thieves know a good tool, and HD is trying to fool the rest of us that their Ryobi tools are any good.
FYI. Ryobi has nothing to do with Home Depot. It's owned by a Hong Kong power tool manufacturer, and used to be Japanese (in fact, Ryobi still exists as a tool manufacturer, just not the power tool division)
Probably the reason they're not in any of the hauls is because they have a reputation for not being very good, and are harder to sell/fence...
If you are a diyer that needs it for maybe 1-2 jobs a year, ryobi is usually not a bad choice.
Personally, I stick with DeWalt because I like quality even though I fall under the “diyer” category. This impact driver has survived 5-6 moves, at least a handful of projects across a few years, and it’s still working as if I just picked it up from the store. Haven’t had to do any maintenance or repairs.
One of the cheaper harbor freight or off brand power tools I picked up many years ago lasted at most 1-2 yrs with only a few projects. Which is the reason I started investing in higher quality (prefer dewalt, but will buy Milwaukee).
If you want gold-plated, there's Hilti, but you're paying a lot extra for a marginal increase in reliability. Milwaukee, Bosch, Makita, and DeWalt are all in the same range, ie contractor/prosumer (and all mostly are manufactured in China). Ryobi is slightly lower but generally fine, ie consumer / price sensitive. Below that is Harbor Freight / no-name electric drill you'd find in am Amazon Basics "essential tools" kit.
Seconded, though I've found the HF Hercules wired line pretty comparable to Dewalt.
But there's a fair amount of inter-model variety within those four/five brands. My 12v Dewalt impact punches above its weight/price and I have two Bosch 18v drills, similar in form factor but one is frankly inferior quality.
And Mafell can be better than festool. Though different manufacturers tend to have different advantages.
Hilti makes some very large tools that if needed Festool does not have alternative. I have also seen a comparably priced Hilti drill/driver give up where a Makita kept going.
WOW I've never heard of festool and hilti but simple googling has turned up amazing stores of their customer service. Unfortunately it looks like they don't overlap completely in the types of tools Ryobi offers.
I really like Ryobi's 18V and 40V 'ecosystem'. Every time I am browsing Home Depot or their website, I come across new items that are compatible with these two ecosystems.
Just recently I saw everything from 18V Ryobi Glue Gun to a Portable Power washer that can suck water from a bucket (eliminating the need for a hose) to even a portable soldering iron! Hell they even got a boombox ha ha!
For the 40V I saw cool things such as a portable power generator, lawn mowers, wet dry vac and even a portable refrigerator.
Its really cool that there are like a bazillion things that your existing batteries can plug into.
Tools are weird like text editors where people get religious about some brands over others. But if your hustle is fencing the most reputable and easy-to-move tools, you would probably want to acquire the standard ones you see in Home Depot and Lowe's, such as Dewalt, Milwaukee, Craftsman, etc. Reputation-wise they're all about the same. Personally I like Makita.
I would say Festool is a brilliant system, but different manufacturers can make better tools for certain jobs. Mafell’s jigsaw is excellent, Metabo for grinders etc, Hilti SDS plus and Max.
Festool domino system I hear is probably the best, but that is rather specialized.
I spent hours researching the various pro-sumer level brands when upgrading my tool collection this winter. And settled on Milwaukee. Because red. Ok fine, their track saw played a part. But mostly red.
CueCam Presenter solves this quite elegantly: You can prepare a script with a card for each window you want to share. Then you can just select the card during the presentation and it will share just that window.
I also have a single large screen. So I put the CueCam window on the right, top to bottom. And the windows I want to share in the bottom left quadrant. There I can make them smaller, with the correct aspect ratio, so that participants with smaller screens can see all the detail they need.
That leaves the top left quadrant for my meeting window where I can see the meeting participants.
I'm also experimenting with the two companion apps: Shoot to use my iPhone camera and control zoom from CCP; and Video Pencil to draw on my video.
Plus one for structurizr. Its model driven approach makes it a lot easier to keep the diagrams consistent with the code: You describe the architecture, and structurizr renders the diagrams.
I've been using https://structurizr.com/ to automatically generate C4 diagrams from a model (rather than drawing them by hand). It works well with the approach for written documentation as proposed in https://arc42.org/. It's very easy to embed a C4 diagram into a markdown document.
The result is a set of documents and diagrams under version control that can be rendered using the structurizr documentation server (for interactive diagrams and indexed search).
I also use https://d2lang.com/ for declarative diagrams in addition to C4, e.g., sequence diagrams and https://adr.github.io/ for architectural decision records. These are also well integrated into structurizr.
Recently been doing the same Structurizr consolidation since amongst our various teams we had a mish-mash of Lucidchart, Miro, and other collaborative design tools.
One thing I was experimenting with (read: struggling with!) was a way to keep per-service (per-repo) architecture workspaces which are also synchronized on-commit to a central workspace and used !include to bind them together. The moving parts are not difficult - but writing your DSLs in a way that can handle this can be. This idea would let individual projects be self-sufficient and generate their own README doc diagrams as part of their own build process; but also have a central site which shows all the services as well as inter-service connectivity.
I looked at the avisi stucturizr-site-generatr, however, decided to render the docs via structurizr-lite. It provides better interactivity for C4 model diagrams, e.g., drilling down into diagrams and tooltips. I found the ADR integration in structurizr-lite sufficient.
I use MermaidJS for flow chart and Sequence diagram. They have C4 in beta. I tried and it is hard adjust the layout and many features are not supported for C4 yet.
I think you mean Visual Studio _Code_. Completely separate product. Not your fault of course, but the geniuses at Microsoft who gave the same name to two different IDEs in an environment where users of the second one are very unlikely to be aware of the existence of the first. Still, it's an important distinction worth knowing about because they have their own distinct extension ecosystems that are not mutually compatible.
Wow ya learn something new everyday. I had no idea but it did seem odd there were two options from our internal software portal to download ides with similar names but the same exact logo.
for C4 structurizr is the best so far I know. I use that for landscape , container diagrams. I got feedbacks that even CIOs are able to get the picture easy. If they have some ways to produce better layouts for large landscape it would be awesome.
Structurizr looks popular but I don't love needing to learn yet another DSL. Does there exist a way to describe things in an existing language with a library?
To use the example on their website, I would like something like this in JS:
let { Component, Container, Diagram, Person } = import 'c4'
let user = new Person('User')
let system = new Container('Software System')
let webapp = new Component('Web Application')
let database = new Component('Web Application')
system.contains(webapp)
system.contains(database)
user.uses(webapp).via('Uses')
webapp.uses(database).via('Reads from and writes to')
export new Digram()
.title('Software System')
.theme('default')
.shows([user, system])
.type('container')
Edit: As it turns out, there are a couple libraries like this:
If you want to create diagrams from textual descriptions, https://kroki.io/ is very versatile and supports several different markup languages including C4.
These DSL tools can be absolutely fantastic and feel powerful in the hands of one person, but the issues come when multiple people get involved.
I train teams to use C4 diagrams, one of the most common issues they tell me they had in the past is the ivory-tower: someone somewhere created all the diagrams alone and dumps them on everyone hoping it will make the world better. The problem is that mode lacks the collaboration and mutual context-building to get everyone on the same page. Not everything needs to be a team effort, but a lot of your diagram work should shift towards a day-to-day tactical discussion (the deeper the C4 level the faster moving things will be). Shifting to a culture of shared context and the discipline of speaking the same language lets everyone have high clarity and move quickly.
The problem with DSLs is they are often nudging people to work alone. Text editors like that are often not multi-player. You can get around it with a screen-share or even pair programming a diagram, but often the tools nudge behaviours of people into a mode where they just work alone and dump stuff out of the ivory tower.
When I train teams who are coming in new to something like C4 I will use Miro specifically because they don't need any special DSL knowledge, and also especially because it is multi-player (everyone gets to draw and move stuff around). I find often people get a bit shy about touching the diagrams but in the training it is really important to get the whole team into the practice of seeing "oh yeah, this is a diagram I can touch too".
For teams who've been through the basic training and gotten used to C4 diagrams to do specific jobs in their tech org, I move them into https://icepanel.io/ because the problems of that team have changed a lot. The initial problem was "I need to know how to structure a story and model my architecture at the same time". Once they got good at explaining their architecture they end up needing to model their architecture (a diagram is something different than a model) at a bigger scale (all those connections that make your diagrams too messy, the boxes that are important in context A but not context B, etc). I like IcePanel because I can slice out a "domain" of my model and show just that view of the world. For teams that have been trained to empower everyone to draw (instead of a single Benevolent Diagrammer For Life), having a multi-player system to manage the model and pick how to present a multi-dimensional subset of that better than just having a static DSL file or a Miro board (note: Miro is "fine" but it can quickly reach its limits). Basically, You get to keep the complexity of your model but only have a focused discussion on the relevant parts.
Beyond that, there's a whole world of techniques on how to actually read an architecture diagram to spot problems, but that's just too much stuff to post in a comment here.
The tl;dr is: Getting your teams to manage their architecture is multiple skills you need to build into the people on your team: collaborating, diagramming, modeling, analysis, and story-telling. I suggest starting in any tool where everyone can participate, and I don't think that's a DSL-based tool because of the UX. Those DSLs "nudge" your culture towards one where one person in the ivory tower drops an inaccurate and overly complicated one-size-fits-all diagram every 9 months and nobody knows with to do with it. It doesn't always happen, but it does increase the chances.
Full disclosure: I'm the trainer mentioned in the article. Happy to answer questions here if anyone wants to debate or pick my brain.
Thanks for mentioning gingkowriter. Youtube video is worth a watch. I will evaluate this a replacement of mindmaps at early conceptual stages in a SW project. Gingko's ability to have rich text nodes, export to plain text/word/JSON will allow me to stay in the outline mode for longer before I commit to sequential documents.
I've started using draw.io [1] for diagrams I want to embed in markdown files. The cool feature about draw.io is that it can embed the data structure describing the diagram in a png file. So you get a PNG file that is both source code for your diagram (so you can edit it later), as well as the presentation (you can embed png files and they will render fine in Github hosted md files).
Then I use the markdown-images package [2] for Sublime Text, and I can see those png images in my markdown files in the editor as well.
Benefits of this approach:
* Powerful diagram editor, free to use.
* Editable diagram and embedable image in one file.
