Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from noahbuscher.com
The 987.2 Porsche Boxster is one of the best values in the used sports car market today. There is so much to love about the vehicle, but the OEM headunit is not one of them. It's very dated, clunky, and doesn't support CarPlay (!), so one of the first things I did after picking up my car was purchase and install a new headunit. I selected the Sony XAV-AX1000 headunit because: It's one of the only aftermarket headunits with a physical volume knob The matte black plastic finish very closely matches my Porsche's interior I didn't need wireless CarPlay It's relatively cheap I also picked up this dash kit from Crutchfield as well to have the install look as factory as possible. I will say that the fit is very tight (it's a friction fit) so triple check wiring before sliding this into the dash. If you do happen to get the kit stuck with the headunit in it, I've had luck freeing it with the help of a metal putty knife. My 987.2 has the Sound Package Plus (SPP), which is the middle tier between the basic speakers and the Bose speakers (which are much more difficult to connect). The connector I needed as a result was the Metra 70-9003 harness. The connector may come with a fuse tap, but I opted to just use a separately purcahsed unit that fit well in the fuse box without needing to drill any holes. Note that the Metra 70-9003 harness may not work with the base package. Other supplies needed: Electrical tape Assorted t-taps Assorted spade connectors Low-profile fuse tap Metra 70-1787 harness (seperate from the Metra 70-9003 harness, this is just a donor for the RCA cables) Stranded red wire (used to connect power from fuse tap to headunit) Banana plug adapter for connecing SiriusXM Tools needed: Heat gun/heat shrink Screwdriver set Soldering iron/solder Wire strippers Scissors Also of note that my Porsche did not come equipped with steering wheel controls. If you vehicle does have steering wheel controls, you may need to purchase extra materials in order to get those to work, if so desired. The first thing I did was assemble the headunit inside of the dash kit and set it aside on my desk. The screws that come with the dash kit don't work great but seem to be able to self-tap into the headunit. Just sure you screw them in flush, otherwise the unit won't fit in the vehicle. Next, it's time to wire the Metra harness. You can view Crutchfield's wiring diagram here. Next, you can splice the donor RCA cables from the 70-1787 harness with the speaker wires in the 70-9003 harness. Using your wire strippers, remove the outer layer of shielding from the RCA cables, exposing the positive wire and the stranded negative wire. Twist the stranded wire together and put the heat shrink tube over the cable. Solder the positive wire to the 70-9003 harness positive wire and solder the negative wire to the 70-9003 negative wire for the same speaker. Wrap each connection tightly with electrical tape, slide the heat shrink over the connections, and use your heat gun to set. Repeat this for the three other pairs of speakers. Moving on to the install, removal of the headunit in the 987.2 is straightfoward, only requiring the removal of a few screws. This YouTube video explains it well. I reccommend disconnecting your battery first if possible, as you should do whenever working with your car's electrical system. Be delicate as the OEM headunit is still valuable and you may want to swap it back before selling your vehicle. You can now remove the trim around the fuse compartment and tap the fuse; I used C6 as it turns on and off with the ignition. Crimp a length of the stranded red wire to the tapped fuse connector and snake it through to the headunit area. I had the wire rest on the trim below the steering wheel and it hasn't caused any issues. Re-attach the fusebox surrounding trim and use a spade connector to attach the fuse tap wire to the power input for the headunit. I wrapped the connection with electrical tape to prevent shorts. At this point you may want to tap the parking lights in order to control automatic dimming of the headunit. I did not do that during my install, so you'll need to look at a diagram to see what color to look out for. I will note, however, that you are able to easily manually dim the display in the settings. Now, plug the RCA connectors into the respective pre-amp outputs on the headunit to connect the speakers. When you disconnected the original factory headunit, there was a twelve-pin blue connector. The pink wire with the red stripe powers the vehicle's amplifier (under passenger seat in SPP-equipped vehicles). I used the "Remote Out" wire in the new headunit to power both the amp as well as the powered AM/FM radio antenna. Use t-taps to connect both the red and white striped wire and the powered antenna wire (thicker, solid blue wire in the main harness). At this point you can also connect the SiriusXM adapter if your vehicle is equipped. Finally, after you've checked all of your connections you can (carefully!) slide your headunit into place, reconnect the battery, and test it out! If you are noticing a fair amount of feedback, you can optionally add an inline ground loop isolator between the pre-amp output and your harness to reduce some of the interference. Enjoy your new radio and feel free to email me and I can try and answer any questions you may have. Please note I am not an expert at this and am not responsible for the safety of yourself or and damage to your vehicle, the headunit, etc.
I have been a dedicated Nova user for over three years. I switched over from VSCode after tiring of the slow performance and "uncanny valley" interface. I'm a sucker for a well-done native app, and Panic really hit the sweet spot with Nova: a beautiful, minimal editor that felt right at home on macOS. It was also extremely fast to boot, indexing files and rendering 50,000 LOC+ without even breaking a sweat on the M1 Pro. Unfortunately, I've been looking for an alternative as of late due to the high frequency of Nova crashes and lack of updates from Panic. Still, the editor scene hasn't changed much from what it looked like half a decade ago, with a smattering of Electron apps, Coda/Nova, some stalwarts such as Sublime Text and TextMate, and, of course, the venerated Vim/Emacs/Neovim trio. I'm not one to spend a lot of time messing around with my tooling; I just want whatever editor I use to have a shallow learning curve and be performant. Somehow, looking for a new editor last week, I came across Zed's tweet: Zed is officially in public beta for macOS! We've been building Zed in Zed for a year now, and here's what we're loving most about it... 🧵 Since then, I've been playing around with and customizing the editor to see what living with a Rust-powered, minimal editor could look like. Install & Setup Zed was very simple to set up; after downloading the '.dmg,' I had an instance ready to code in a matter of seconds. That's instant points over terminal-based editors. I will note here that Zed is currently only available on macOS. Support for Linux and Windows, according to the team, is: [...] planned, but it is not being prioritized in the short term. Customizing the editor was also very straightforward. They have a default editor configuration that you can use, but I found it easier to open a custom settings file and see what was available via their beautiful autocomplete. There are a few things that I was surprised I wasn't able to customize yet, such as: Setting the interface's font Setting the interface's font size, independently of the editor Enabling (or disabling) icons or colors for the file tree view Allow hiding hidden files Performance This is where Zed really shines. Loading a package-lock.json with over 7500 lines is instantaneous—quite literally. Even Nova would take at least a few hundred ms to parse and color a blob of that size, however, Zed doesn't even flinch. There is also zero scroll lagging, autocomplete delays, etc. that I could notice in any of my testing. I'm not sure of the actual numbers, but in my initial testing, Zed felt like the fastest editor I've ever used. That is to be expected, of course: the editor was written in Rust and, as stated in their docs, performance was a top concern while developing the app over the course of this past year. Put another way, VSCode is a 2000's Land Rover Discovery with tons of buttons and features, whereas Zed is a sleek McLaren F1 - minimal, extremely fast, and with three front seats. Why three front seats? Multiplayer Zed's big bet is on multiplayer. The editor comes with first-class support for real-time pairing, bundled right into the editor. By no means do you need to use the feature in order to derive a lot out of Zed, however, as more people hop on the Zed bullet train, I can see it becoming an integral part of many people's (and companies') workflows. As stated by the team: [Multiplayer] makes it easy to have nuanced, real-time conversations about any part of your codebase, whether the code in question was committed last year or hasn't yet been saved to disk. VSCode does have Live Share, but it feels tacked on to the interface, whereas in Zed, pairing feels just like any other feature within the editor: seamless. It almost invites you to collaborate with your team. Ecosystem As Zed is still in public beta, there is surely a lot coming down the pipeline. For the time being, however, there were a few features I definitely missed from Nova: No extension market (1st or 3rd party) No way to add/edit themes (it comes pre-bundled with a number, however) No dark/light mode based on system Limited git integration No markdown preview Limited language support No spellcheck I could not find anything regarding Zed Industries' plan for supporting extensions (if there even is one), however, I hope they do allow for writing extensions with a scripting language such as JavaScript. Forcing developers to build in Rust may be good for performance, but in a world where everyone is building VSCode extensions, it will cripple the marketplace's offerings from the start. Besides the aforementioned list, Zed really has most of the niceties I'm used to built right in. I have come across a few small bugs, which is to be expected at this stage of development, but none of which have detracted me from getting my work done. Recap Zed is a fantastic editor - it's eye-wateringly fast, extremely minimal (and beautiful), has a talented team behind it, and is a natural transition for anyone who has familiarity with both terminal and GUI-based editors. However, in a world that is dominated by the free, open-source VSCode, I am curious to see how Zed's extension ecosystem grows and what Zed Industries' plan is for monetizing their product. For the time being, I have found the editor a pleasure to work with, and I will be using Zed as my daily driver moving forward. If you're tired of VSCode's large size, cluttered interface, and slow performance, I urge you to download Zed's beta and give it a try. I think you'll be pleasantly surprised.
More in technology
It is a story as old as time (or at least the 1960s): kid gets an RC car for Christmas and excitedly takes it for spin, but crashes it into a wall within five minutes and tears ensue. The automotive industry has cut down on accidents by implementing automatic emergency braking safety features, so why […] The post This automatic emergency braking system protects RC cars appeared first on Arduino Blog.
The shortest distance between your thoughts and the printed word.
It isn’t a secret that many kids find math to be boring and it is easy for them to develop an attitude of “when am I ever going to use this?” But math is incredibly useful in the real world, from blue-collar machinists using trigonometry to quantum physicists unveiling the secrets of our universe through […] The post This unique electronic toy helps children learn their shapes appeared first on Arduino Blog.
I have worked with a few software developers who made the switch to this industry in the middle of their careers. A major change like that can be scary and raise a lot of fears and doubts, but I can attest that this can work out well with the right personality traits and a supporting environment. Here’s what I’ve observed. To keep the writing concise, I’ll be using the phrase “senior junior”1 to describe those that have made such a career switch. Overcoming the fear Fear is a natural reaction to any major change in life, especially when there’s risk of taking a financial hit while you have a family to support and a home loan to pay. The best mitigation that I’ve heard is believing that you can make the change, successfully. It sounds like an oversimplification, sure, as all it does is that it removes a mental blocker and throws out the self-doubt. And yet it works unreasonably well. It also helps if you have at least some savings to help mitigate the financial risk. A years’ worth of expenses saved up can go a long way in providing a solid safety net. What makes them succeed A great software developer is not someone that simply slings some code over the wall and spends all of their day working only on the technical stuff, there are quite a few critical skills that one needs to succeed. This is not an exhaustive list, but I’ve personally observed that the following ones are the most critical: ability to work in a team great communication skills conflict resolution ability to make decisions in the context of product development and business goals maintaining an environment of psychological safety Those with more than a decade of experience in another role or industry will most likely have a lot of these skills covered already, and they can bring that skill set into a software development team while working with the team to build their technical skill set. Software development is not special, at the end of they day, you’re still interacting with humans and everything that comes with that, good or bad. After working with juniors that are fresh out of school and “senior juniors” who have more career experience than I do, I have concluded that the ones that end up being great software developers have one thing in common: the passion and drive to learn everything about the role and the work we do. One highlight that I often like to share in discussions is one software developer who used to work in manufacturing. At some point they got interested in learning how they can use software to make work more efficient. They started with an MVP solution involving a big TV and Google Sheets, then they started learning about web development for a solution in a different area of the business, and ended up building a basic inventory system for the warehouse. After 2-3 years of self-learning outside of work hours and deploying to production in the most literal sense, they ended up joining my team. They got up to speed very quickly and ended up being a very valuable contributor in the team. In another example, I have worked with someone who previously held a position as a technical draftsman and 3D designer in a ship building factory (professionals call it a shipyard), but after some twists and turns ended up at a course for those interested in making a career switch, which led to them eventually working in the same company I do. Now they ship builds with confidence while making sure that the critical system we are working on stays stable. That developer also kicks my ass in foosball about 99% of the time. The domain knowledge advantage The combination of industry experience and software development skills is an incredibly powerful one. When a software developer starts work in a project, they learn the business domain piece by piece, eventually reaching a state where they have a slight idea about how the business operates, but never the full picture. Speaking with their end users will help come a long way, but there are always some details that get lost in that process. Someone coming from the industry will have in-depth knowledge about the business, how it operates, where the money comes from, what are the main pain points and where are the opportunities for automation. They will know what problems need solving, and the basic technical know-how on how to try solving them. Like a product owner, but on steroids. Software developers often fall into the trap of creating a startup to scratch that itch they have for building new things, or trying out technologies that have for a very long time been on their to-do list. The technical problems are fun to solve, sure, but the focus should be on the actual problem that needs fixing. If I wanted to start a new startup with someone, I’d look for someone working in an industry that I’m interested in and who understands the software development basics. Or maybe I’m just looking for an excellent product owner. How to help them succeed If you have a “senior junior” software developer on your team, then there really isn’t anything special you’d need to do compared to any other new joiner. Do your best to foster a culture of psychological safety, have regular 1-1s with them, and make sure to pair them up with more experienced team members as often as possible. A little bit of encouragement in challenging environments or periods of self-doubt can also go a long way. Temporary setbacks are temporary, after all. What about “AI”? Don’t worry about all that “AI”2 hype, if it was as successful in replacing all software development jobs as a lof of people like to shout from the rooftops, then it would have already done so. At best, it’s a slight productivity boost3 at the cost of a huge negative impact on the environment. Closing thoughts If you’re someone that has thought about working as a software developer or who is simply excited about all the ways that software can be used to solve actual business problems and build something from nothing, then I definitely recommend giving it a go, assuming that you have the safety net and risk appetite to do so. For reference, my journey towards software development looked like this, plus a few stints of working as a newspaper seller or a grocery store worker. who do you call a “senior senior” developer, a senile developer? ↩︎ spicy autocomplete engines (also known as LLM-s) do not count as actual artificial intelligence. ↩︎ what fascinates me about all the arguments around “AI” (LLM-s) is the feeling of being more productive. But how do you actually measure developer productivity, and do you account for possible reduced velocity later on when you’ve mistaken code generation speed as velocity and introduced hard to catch bugs into the code base that need to be resolved when they inevitably become an issue? ↩︎
I uploaded YouTube videos from time to time, and a fun comment I often get is “Whoa, this is in 8K!”. Even better, I’ve had comments from the like, seven people with 8K TVs that the video looks awesome on their TV. And you guessed it, I don’t record my videos in 8K! I record them in 4K and upscale them to 8K after the fact. There’s no shortage of AI video upscaling tools today, but they’re of varying quality, and some are great but quite expensive. The legendary Finn Voorhees created a really cool too though, called fx-upscale, that smartly leverages Apple’s built-in MetalFX framework. For the unfamiliar, this library is an extensive of Apple’s Metal graphics library, and adds functionality similar to NVIDIA’s DLSS where it intelligently upscales video using machine learning (AI), so rather than just stretching an image, it uses a model to try to infer what the frame would look like at a higher resolution. It’s primarily geared toward video game use, but Finn’s library shows it does an excellent job for video too. I think this is a really killer utility, and use it for all my videos. I even have a license for Topaz Video AI, which arguably works better, but takes an order of magnitude longer. For instance my recent 38 minute, 4K video took about an hour to render to 8K via fx-upscale on my M1 Pro MacBook Pro, but would take over 24 hours with Topaz Video AI. # Install with homebrew brew install finnvoor/tools/fx-upscale # Outputs a file named my-video Upscaled.mov fx-upscale my-video.mov --width 7680 --codec h265 Anyway, just wanted to give a tip toward a really cool tool! Finn’s even got a [version in the Mac App Store called Unsqueeze](https://apps.apple.com/ca/app/unsqueeze/id6475134617 Unsqueeze) with an actual GUI that’s even easier to use, but I really like the command line version because you get a bit more control over the output. 8K is kinda overkill for most use cases, so to be clear you can go from like, 1080p to 4K as well if you’re so inclined. I just really like 8K for the future proofing of it all, in however many years when 8K TVs are more common I’ll be able to have some of my videos already able to take advantage of that. And it takes long enough to upscale that I’d be surprised to see TVs or YouTube offering that upscaling natively in a way that looks as good given the amount of compute required currently. Obviously very zoomed in to show the difference easier If you ask me, for indie creators, even when 8K displays are more common, the future of recording still probably won’t be in native 8K. 4K recording gives so much detail still that have more than enough details to allow AI to do a compelling upscale to 8K. I think for my next camera I’m going to aim for recording in 6K (so I can still reframe in post), and then continue to output the final result in 4K to be AI upscaled. I’m coming for you, Lumix S1ii.
