DEV Community: Maniflames

Where do intermediate and/or slightly more advanced devs go?

Maniflames — Wed, 01 Dec 2021 20:00:18 +0000

It has been quite a while sincd I've written my kast post here on dev. There isn't a lot I've done with intension or focus. I also don't know if anyone is following me with some sort of intension on purpose.

I'd love to start writing again especially on the stuff that I'm currently exploring. The problem is most of it isn't purely webdev related and other topics are extensions on what I'm exploring during my masters (think applied evolutionary algorithms, applied deep learning, shaders, etc).

On the internet I'm not really someone so regardless of what I do, I'll most likely be screaming in the void. My main question is should I still scream in this void? Part of the reason why people like DEV (or Codenewbies which I relate to each other since the acquision) is that it is beginner friendly. Don't get my wrong I love writing about topics in way that they become more approachable but most of what I want to write about assumes the the reader is able to translate a (basic) algorithm into code.

Should I just jump in and see how it goes or just exclusively write on my own site?

Additionally I've noticed a lot of folk I follow on twitter because of the DEV community don't seem to be on DEV anymore. Is this platform slowly dying or does that have to do with developer maturity?

Time for focus

Maniflames — Fri, 01 May 2020 00:46:57 +0000

I usually post a heavily though out post on a random topic that interests me at the time. My last post was an exception and this one will be as well.

Lately I've been feeling as if I'm running out of time. Currently I'm in the last year of my bachelors but decided to do a 2-year masters because the creative dev industry seems on hold. Even though I'm most likely going to graduate this year I feel like I haven't 'achieved' a lot.

I know mostly web development and have created websites and web apps at a creative agency as something on the side. After actively looking for other types of development I noticed two interesting domains: embedded systems & computer graphics.

I've explored both but because of my split attention I haven't really had the chance to dive deep and learn/build in a way that can be shared. Because my interests are based on the low-level development aspect, keeping up a 'once-a-month' upload schedule on dev will be kind of hard to maintain.

For the past couple of days I've been watching Tae'lur Alexis' live-streams on twitch and asked how she navigates her learning process based on all of the interests that she has. Her answer boiled down to: 'I pick something and stick with it'. Even though it is a really common piece of advice, this was the first time I 'got it'.

It was really hard to pick between hardware and graphics for the three month dev exploration I want to do to dive deeper. I decided to flip a coin. Heads for graphics, tails for hardware. I got heads.

There are still a few things I have to figure out but I want to stick to graphics for a while and work from there. It'll be web based at first but I'm pretty sure that'll change too.

If you are one of the 5k people that follow me here on dev and got this far, thank you. Seriously. I hope my journey will at least be interesting to you in the future.

I feel worthless when I'm unproductive

Maniflames — Tue, 31 Mar 2020 18:02:21 +0000

For the past two weeks I have been working from home because of instructions from the government in response to COVID-19. The timing isn't super great, but to be fair the timing probably isn't great for anyone.

During my time at home my 'work life' and my private life slowly merged into one, even though I came up with a schedule in an attempt to prevent this exact thing from happening. Another rule was to make sure that the weekends would be off limits for anything work related, unlike usual. That didn't happen yet. This conflict is not necessarily new, but now that I'm stuck in my bedroom for most of the time it has become a lot more visible.

It's just really hard to sit still because there are a lot of things I could do instead. Extending my portfolio, continue my OSSU journey, finally start leetcoding or finally building one of those ideas I had in mind. I don't believe there is anything wrong with doing any of this next to work. However, it does become a problem when you 'have' to do them and can't stop. The very obvious thing to do in a situation like this is slowing down.

I have tied a very big portion of my identity to working hard and achieving things. Not on purpose but because others seem to value that as well. I 'work hard', 'always try to get the best out of myself' and 'am always doing something and headed somewhere'. And those little dopamine hits feel great but at the same time I feel like I'm approaching either depression or burn-out. No matter what I do it has to be useful in some way or I should not have been thinking about it in the first place.

If someone asks me where I'm going, I have to at least know where I'm headed. If I join a team, I better put in as many hours as I can. I'm still in school and very junior. There is a lot to learn and there is no alternative to putting in actual work if I want to get better. I don't have a popular open source project yet. I haven't even made a pull request on projects that inspire me. I'm not doing great, I'm lying to myself and believe the statements of people who mindlessly put on their rose colored glasses. There are still a ton of side projects on the shelf. I have potential but that is literally all that I've got. I have to work, I have to work, I have to work.

If I try to sit still those thoughts become louder and louder until I give in and start working again. Why would I do otherwise? If I don't work, why am I here? Who would care about me? What's the point?

Last year I reached out to my class' supervisor to explain that I really didn't feel like being here anymore. It wasn't the first time thoughts like these have crossed my mind and I had received help from a kids psychologist back in high school. Of course my supervisor wasn't allowed to deal with these things and about two weeks later I had to sit down with my college's psychologist. Luckily, I don't have to worry about anything because according to him I'm doing great. I have a strong personality, excellent grades and could express myself clearly during the conversation. The best thing I could do was read a book by Carl Gustav Jung and make another appointment if I still felt the need to get rid of myself. That was the first and last time I spoke to him.

I'm not going to lie, I haven't read a single word of any of Jung's books and maybe I should have. Instead, I spend some time on YouTube watching video's from random people with their take on hustle culture and ambitious minimalists who take it easy.

I feel stuck and lonely at times but whenever I read posts by overwhelmed beginners on Reddit or Dev I just wonder how normal this is in developer land. Do you grow out of this as a senior? I'd love to know how to stop looping between 'hustle' and 'trying to slow down'. Until then, I'm probably working on something and headed somewhere.

Ego is the enemy: overcoming your own thoughts

Maniflames — Sat, 29 Feb 2020 15:14:08 +0000

About a month ago I entered the last five months of my college experience. This last semester consists of an internship that has to result in a Bachelor thesis. Repeating 'this project has to turn out right or I might as well not write a thesis at all' has caused me to overthink everything. The moment I noticed this, I realised I needed something to calm me down. There was one book that I had laying around that has always been interesting to me but I didn't finish until now. I'm glad I picked it up and read it all.

Ego is the Enemy by Ryan Holiday is a book about dealing with your own thoughts and self-sabotage during different stages of life: Aspiration, Success and Failure. The advice in this book has helped me with shaping my thought process into something that helpful instead of hurtful. There are a lot of 'nuggets' in this book I really recommend reading it. In this post I'd like to share my favourite advice, which happens to be the advice that helped me the most.

Aspiration

Most of us have goals and, whether they are big or small, we think about them often. We talk about them with people we respect and love. We visualise them and try to experience a bit of the success we think we'll feel when we achieve them. There is nothing wrong with any of that, but it's easy to take this too far. Instead of doing the work we talk about doing the work and confuse it with actual progress. Even when we are working on our goal, our idea of what success looks like slowly steers us into a different direction. It is suddenly about impressing others instead of reaching goals. Solving a big pile of small JIRA tickets instead of solving a bigger bug that will take more time and effort. Over-engineering something a just little, so we can flex instead of writing something that can easily be understood by everyone.

The only way to overcome this is by noticing it yourself. Other people might be indifferent to your actions but you know when you are trying to impress others and slow yourself down. Learning to get out of your own head and step back can help you with actually achieving your goals. If you can redirect your focus from looking for validation to doing the work you need to do, the likelihood of reaching success will be bigger.

Success

Achieving a goal you have wanted to achieve for a while feels amazing. You're finally there. You got the job, you're promoted to senior or you finally launched that product. Is this the end? Is this the start of becoming bigger and better than anyone else? When success gets into your head it can trap you in two ways: complacency or endless ambition.

When you are hired it's done right? You can sit at your desk, type a bit of code and go home afterwards. You have build some CRUD applications before, all you have to do is repeat it. Unfortunately, having done something successfully in the past is not a guarantee you can repeat that success forever. Don't blindly write code without running it because you have written something similar before. It's easier to debug something if you made a small change than when the bug is hidden under 100+ lines of code.

In that case being hired is just the start right? Keep studying. Read about development before work. Don't leave until the last dev does. Code until the middle of the night as soon as you get home. Don't stop until you're at the top. What is the top exactly? CTO? Do you even want to be CTO? A lot of developers realise they don't when they discover that a CTO barely touches code and focusses more on drawing the architecture. Putting in endless hours to reach the top often leads to burn-out. Make sure you define your next step based on what you want.

The author was able to summarise all of this in one sentence: "The only way to manage success is to manage yourself." Goals are our way of defining happiness and fulfilment but as soon as we are 'too good' or must 'grind endlessly' success turns into something meaningless. It's difficult to not fall into complacency or endless ambition. That is why it is hard to stay successful. No matter if you fall for one trap or the other without managing yourself you'll end up failing.

Failure

A mistake doesn't need to be big to get to us. Getting notified that your pull request is rejected. Shipping the bug into production. Not recalling something that is considered base knowledge. It can happen to anyone. The way we respond to these events is what will determine wether that mistake is a failure. Being defensive, covering things up or wanting to prove someone wrong can easily lead to behaviour that will hold you back. Most people know that it's important to learn from your mistakes. What not a lot of people realise is that fighting mistakes often leads to more of them.

Wanting to avoid failure often means wanting to make sure other people don't perceive the consequences of our actions as failure. However we can't control the thoughts of others. A lot of times we can't even control the outcome of our work, all we can do is adopt a process optimised for success. Letting go of both external opinions and outcomes we can't control is key to moving on. Take notes, adjust the process where necessary and try again. Being less attached to outcomes often leads to better results because it allows for more focus on the process.

You don't have to do anything wrong to achieve what others perceive as failure. You might receive less than 100 views on that tutorial you worked on for weeks. Your pull request could be rejected because the team decided to move their project in a different direction. That doesn't mean that your tutorial didn't help anyone or your contribution contained unmaintainable code. Not being rewarded for the effort in the way that you or others expect does not mean you should not have taken that action at all. The only failure in that case is letting those things get to you.

Most thoughts and instances of self-sabotage are rooted in insecurities of what we think others think about us. Letting go of those thoughts is the key to happiness and, in the long run, success.

From web to embedded: exploring a different sub-field within tech

Maniflames — Fri, 31 Jan 2020 21:57:19 +0000

For the past few years I have had the pleasure of learing software development. Like a lot of others, I initially focused on the web. The large amount of YouTube channels, blogs, podcasts, online courses and communities like DEV make web development very accessible to newcomers. Over time however I realized that, although I love the web, I wanted to build something that wouldn't disappear once you close your laptop.

Apart from building a few 'Hello World' projects on popular boards like the Arduino and Raspberry Pi, I didn't have any experience or fundamental knowledge about development for hardware. It was hard to figure out where to start to push past the hardware tutorial stage. That is why I decided to minor in embedded systems. Now that I have completed my minor I'd love share an overview of some of the things I have learned. Over time I realised that this read is pretty long and I figured that you might want to skip parts here and there. So I made a table of contents that allows you to do that.

What is an Embedded System?
Building an embedded system
- Research and experimentation
- Design
- Implementation
- Testing
- Deployment
Software development: web vs embedded
- Industry languages
- Moving between 'frameworks'
- Math
- Binary
Keeping your head up
- Loneliness
- Imposter syndrome
Some cool places and faces in the community
- News and project sharing
- Influential companies
- Learning communities
- Educational people
- Inspirational people

What is an Embedded System?

A lot of people disagree on the exact definition of an embedded system. My favourite definition, even though the engineer who said it doesn't see it as a complete one, is:

An embedded system is a computerized system that is purpose build for its application.

-- Elecia White during 'A Gentle Introduction to Embedded Systems', a presentation for her book 'Making Embedded Systems'.

To simplify the language that she uses: An embedded system is a (often tiny) computer that is build to perform one (or a few) specific task(s). Under this definition some examples of embedded systems are smartwatches, microwaves and the engine control unit in a car.

Building an embedded system

Embedded systems that are build from scratch require custom PCBs (Printed Circuit Boards). The goal is to build the smallest computer possible that will still meet the strict performance requirements. There is also a possibility some functionalities should be build with hardware instead of programmed within the software. The main reason for picking hardware over software is speed. Software on an embedded system is usually written in C or C++ and works with a RTOS (Real Time Operating System), embedded linux or no OS at all.

The hardware part of the process aligns a lot more with EE (Electrical Engineering) than with CS, software engineering or software development. This is why, at my college, the embedded systems minor is hosted by the EE department. It is also the main reason why it takes some time to switch from web to embedded. Even if you are a developer that puts the focus on the software within an embedded system, you need the know hardware fundamentals in order to properly debug your code.

The creation of an embedded device has a couple of stages which don't strictly happen one at a time. Each of these stages require different skills, knowledge and tools.

Research and experimentation

When the goal and the requirements of the project are clear, it's time to look for the hardware you need. This is often a combination of, but not limited to, a microcontroller or microprocessor, sensors, ICs (Integrated Circuits), resistors, capacitors and transistors.

In this fase it's important to try things out. That is why you'll most likely use a development board for a specific microcontroller and connect it to different sensors with jumper wires on a breadboard. If you have played around with electronics before you probably know the Arduino Uno, a development board that simplifies the development for the ATmega328. There are a lot more development boards and even more microcontrollers that might bring you closer to your goal. In this stage you'll mostly write software to see if you can get everything up and running.

Datasheets will help you to understand the features, usage and configuration of all the hardware components. These datasheets can range from a single page for simple LEDs to hundreds of pages for a microcontroller.

There is a possibility that some parts can't be placed on a breadboard or have a high chance of breaking when configured incorrectly. It's a good idea to simulate these parts and see if you can figure out the right configurations based on information in the datasheet. A popular free solution that can be used to do this is LTspice.

Design

When a development version or small prototype is done, you can start documenting and finalizing the hardware design. A few popular tools for designing hardware are KiCAD, EasyEDA, Eagle and Altium.

The first thing that has to be created is a schematic capture. This is a visual representation of all the hardware components you'll need. Depending on the size of this diagram, the connections between the components are specified with lines or labels.

The next step is the PCB design. This design uses all the components specified by the schematic capture. You can draw a board, place components, draw traces ('wires' on the board), drill holes and place text. When the PCB design is done you can generate gerber files so a factory can produce your PCB.

Besides designing the hardware it is also imported to write down some UMLs or flow charts of the (most important) software that will be put on the microcontroller.

The schematic capture and flowcharts end up in a datasheet of the designed hardware. Additionally pin defentions, possible configurations, operating temperatures, operating voltages and sometimes even example circuits are added to the datasheet as well.

Writing and checking a datasheet can take a lot of time. That is why it might be a good idea to send the gerber files to a factory before starting this process since manufacturing the designed PCB and shipping will take time as well. It's also smart to create a list of all electronics components that need to be put on the PCB, also called a BOM (bill of materials) and order all those components as well.

Implementation

When the PCB and components are in, it's time to solder. Depending on the size of the electronic components a solder iron, hot air or even a special oven can be used to stick the components to the PCB. In case some components have a small SMD (Surface Mounted Device) packages you may have to use a microscope to make sure pins aren't soldered together.

Then the circuit can be tested or debugged using various tools like a multimeter, signsal generator, ocilliscope and/or logic analyser. These tools can also be used during the development stage if a development circuit isn't behaving like it should.

In case there is a problem in the PCB design, that can't be corrected by desoldering some components or soldering some extra wires or resistors to the board the design has to be fixed in the software and the PCB and components have to be re-ordered.

This is also the moment the full application that has to run on the microcontroller is completed with all the necessary optimisations (if that hasn't been done already).

Testing

If there is a version of the hardware that can be tested it is time to perform unit, integration and finally acceptance tests. The unit test is a test where controlled inputs and outputs are 'written' and read from the design. If the right signals come back within a specified time-frame in various condition it passes the test. The integration test is done when your hardware has communicate with other pieces of hardware. If that communication goes well it passes the test.

The acceptance test should only be done with a PCB that contains the final design and didn't need any extra debug hardware fixes. In this test the full system will tested to see if all requirements of the system are met.

In some cases specific test results and behaviours are put in the datasheet as well.

Deployment

When all the test pass you hand over the physical product, designs and documentation. It's time to celebrate since this process can take months or even years.

Software development: web vs embedded

Embedded software development and web development have a few similarities. The most general skills that will help in both types of development are logical/computational thinking, creating algorithms, debugging, clean code and creating useful comments and documentation. What makes or breaks embedded software development for an individual lies within the differences.

Industry languages

The web is extremely diverse. Although a combination of HTML, CSS and JS on the front-end is the norm, there are quite a lot of front-end frameworks out there. Besides that a lot of different languages can be and are being used on the back-end. You could look for a back-end position right now and encounter: PHP, Python, NodeJS, Ruby, C#, Java and a lot more.

The embedded systems industry shows a clear preference of C and C++. This is mainly because these languages have the toolchains to compile for nearly any microcontroller. The control over memory also makes the use of these languages ideal. Python seems to grow in popularity as well. This could be because of the release of micropython. I've also seen some anecdotes on reddit of how Raspberry Pi compute modules are used on PCBs. Another interesting language is Assembly which is mainly used for small pieces of software that need to meet strict timing deadlines.

Other notable languages are VHDL and Verilog which don't produce code that runs on a machine but a hardware design that can be adopted by a FPGA (field-programmable gate array). This is an IC that can change its own circuit. So instead of writing software you are writing hardware.

Moving between 'frameworks'

If you happen to be a web developer that has switched jobs or works at an agency that has multiple stacks in production right now you'll know what it feels like to switch between frameworks. If you are lucky most concepts stay the same, making it mostly a matter of learning syntax.

Being able to write efficient software for a specific 'family' of microcontrollers is similar. It means you'll have to learn what features are available and in what ways the microcontroller can be configured. Due to the amount of differences between most families however it could be seen as picking up a new programming language rather than picking up a new framework. Other than that it's very similar. The first one will be hard but moving on to another family afterwords should be relatively easy. The biggest hurdles will probably be some newly introduced concepts tied to specific features and the Assembly language of the specific chip.

Math

The most common web applications don't require math beyond high school level. Besides that you can trust that most of your users have a processor that is powerful enough to handle complex math within a certain amount of time.

Within embedded software development there are often some processes that require math that ranges from high school level to calculus on microcontrollers that are often not powerful of fast enough. A great example of one of these processes is DSP (Digital Signal Processing). This is used for processes video and audio and requires some calculus. Meeting the requirement or even making sure the application works means you have to pre-calculate coefficients and use mathematical tricks like fixed point numbers.

Additional hardware can be added to take some of the pain away but that will increase the cost of the device. Some things might have been implemented by someone online but run too slow in your specific application. Don't worry too much about calculating those coefficients though. Tools like matlab and miniDSP can help with that. The most important is that you know how to type of mathematical functions you will need to apply to reach your desired outcome (or at least how to translate them to code after googeling). The same goes for all the other cases math is needed (increasing accuracy of sensors, increasing speed,

Not all systems don't need heavy math and everything can be learned so don't let that scare you!

Binary

The use of binary is another thing that isn't really used in web applications. However all input signals from external sensors are ones and zeroes. Depending on which abstraction layer you code you may have to configure a microcontroller by changing bits and figuring out bitmasks. Again don't let this scare you, anything can be practiced.

Keeping your head up

A switch between fields can take its toll on you. Right now this is written from the perspective of taking a minor from a major in a different building. However, I strongly believe that these feelings are really universal and apply to situations beyond college and will occur after any major switch.

Loneliness

Stepping into a new environment makes most people nervous. No matter how introverted or extraverted you are, as humans we want someone to connect to. In most cases you'll be fine, unfortunately my 'nightmare' manifested itself making the first four weeks of my minor very difficult on an emotional level as well.

As the only the only on from my major and a non stereotypical electrical engineering look a lot of people gave me the 'don't even bother, you'll drop out anyways vibes'. Don't beat yourself up if classmates joke amongst eachother that they don't want to sit next to you, teachers randomly ask you of they should repeat material in a non-native language or if you sit alone for the first few breaks. Do know that you have to make a decision, is what you want to learn really worth the emotional hit? In my case I determined it was but I also made sure I did the following:

Text my close friends when possible
Taking on a hobby that involves being with other people
Make sure I make time to spend time with family

Over time people realised I wasn't going to drop out and I have defintely noticed I earned some respect because of it. Besides that the project team I'm on slowely started to bond. So there were people I could say good morning to and to be fair from that moment on a lot of loneliness issues started to fix itself.

Imposter syndrome

The classic imposter syndrome will creep up at some point. Especially if you are surrounded by people with a specific foundation you don't have remind yourself that you are new to all of this. A growth mindset is the most important thing you need to develop to stay on track. Make sure to write down all the things you learn and keep the work you can. Looking at everything you have accomplished up until this point can have a theraputic effect.

Some cool places and faces in the community

A switch is never just about technical skills, you'll be surrounded by a different community with different interests, values and key players. There are various resources and places to learn more about hardware and embedded systems. This is a list of my favourite go to places and people on the internet.

News and project sharing

Hackaday.com
Hackaday.com is a site that shares the latest news for within the electonics and maker community. They also host the 'superconference' and share interesting projects from their community websites.

YouTube: HACKADAY
Twitter: @hackaday
Instagram: @hackaday
Github: @Hack-a-Day
Personal favourite: Teaser: 2019 Hackaday Superconference Badge

Hackaday.io
Hackaday.io is a platform that to showcase your hardware/software/embedded projects and interact with other makers. This is the community site of hackaday.com. There are a lot of cool projects that share components and files that allow you to rebuild it yourself.

Twitter: @hackadayio
Personal favourite: Ferrofluid Display

Hackster.io
Hackster is another platform which allows you to share projects. Most projects come with a very detailed description of how to build them yourself and are mostly based on development boards and popular platforms like Arduino and Raspberry Pi.

YouTube: Hackster.io
Twitter: @Hacksterio
Instagram: @hacksterio
Github: @hacksterio
personal favourite: Sequino

Influential companies

Adafruit
Adafruit is an American company that designs, produces and sells hardware that can be used by from beginners to advanced makers. Besides that the company has made a lot of open source libraries and also teaches about electronics through their learning platform and blog. Adafuit's products are also sold by (web)shops that are based outside of the use because of their quality and accessibility.

YouTube: Adafruit Industries
Twitter: @adafruit
Instagram: @adafruit
Github: @adafruit
Hackster: Adafruit Community
Personal favourite: Limor Fried, Founder & CEO, Adafruit Industries

Sparkfun
Sparkfun is another American company that designs, produces and sells hardware that can be used by both beginners and advanced users. Their products are also sold by shops based outside of the US because of quality and accessibility. They produce open source libraries and have a learning platform and a blog as well. What makes Sparkfun so cool is that they share all the design files of their self made products. This means you can not only buy them but see exactly how they are made and maybe even make some adaptations and send it off to the factory yourself.

YouTube: SparkFun Electronics
Twitter: @sparkfun
Instagram: @sparkfun
Github: @sparfun
Hackster: Sparkfun Community
Personal favourite: PCB Basics

Learning communities

All about circuits
All about circuits is a platform for electrical engineers that provides an open source textbook, news, tools and a forum. The educational content, especially their textbook, is extremely useful for hardware beginners. The fundamentals of electronics are explained in a slow pace with analogies and drawings. They also have a youtube channel that they use to introduce new mouser products.

YouTube: All About Circuits
Twitter: @AllAboutCircuit
Instagram: @all_about_circuits
Github: @AllAboutCircuits
Personal favourite: Electronics Textbook

Element14
Element 14 is another community with a forum (and a shop). They took over the ben heck show on youtube and share both entertaining and educational content based on electronics. I personally love the learning circuit because it teaches theory behind common concepts that are used in popular projects.

YouTube: element14 presents
Twitter: @E14Community
Github: @element14
Personal favourite: the learning circuit

Educational people

Great Scott
For electronics tutorials & fun projects Great Scott is one of the best youtube channels out there. He doesn't just walk you through what he does but also explains why he does certain things. This helps you to build your understanding of electronics in an entertaining way.

YouTube: GreatScott!
Twitter: @GreatScottLab
Personal favourite: How to create a simple Touchscreen GUI || Arduino LCD & Touchscreen Tutorial

Afrotechmods
Afrotechmods is another youtube channel that explains a lot about electronics and presents some projects from time to time. Unfortunately the last upload (as of writing this blogpost) was a year ago. However the creator is pretty active on twitter and has a Udemy course on how to build wireless charging circuits with a very good rating.

YouTube: Afrotechmods
Twitter: @afrotechmods
Personal favourite: How to make an LM386 audio amplifier circuit

Shawn Hymel
Shawn Hymel can be seen as another hardware advocate that has created educational videos and tutorials for Sparkfun, Adafruit. He has his on youtube channel on top of that. His tutorial series on KiCAD for Digi-Key is a really good start if you want to make your first PCB. Besides that he also has a tutorial series on Arduino and how to take your Arduino skills to the next level.

YouTube: Shawn Hymel
Twitter: @ShawnHymel
Instagram: @shawn_hymel
Github: @ShawnHymel
Hackaday: @ShawnHymel
Hackster: Shawn hymel
Personal favourite: Level Up Your Arduino Code: Registers

Bitluni
Bitluni is another maker with a youtube channel and a blog. He has build some very cool projects with a pretry populair development board called the ESP32. Not to long ago he posted a video on how he build a shield that transformed his ESP into a video game console.

YouTube: bitluni's lab
Twitter: @bitluni
Instagram: @bitluni
Github: @bitluni
Hackaday: @bitluni
Personal favourite: Arduino Game Controllers

Ben Eater
Ben eater has the best youtube channel out there for people who would like to know how a computer works. He has a series in which he builds an 8-bit computer from scratch and explain how every part of it works. If you want to dive in the deep you can even buy the parts he uses and build your own!

YouTube: Ben Eater
Twitter: @ben_eater
Github: @beneater
Personal favourite: Building an 8-bit breadboard computer!

EEV Blog
EEV Blog is a Youtube Channel created by Dave Jones that has been around for ten years right now! It is centered around embedded systems and electrical engineering and covers a lot of topics from the use of different tools to the explaination of concepts around hardware.

YouTube: EEVblog
Twitter: @eevblog
Instagram: @eevblog
Github: @EEVblog
Personal favourite: EEVblog #1176 - 2 Layer vs 4 Layer PCB EMC TESTED!

Inspirational people

Jorvon 'Odd Jay' Moss
Jorvon Moss or 'Odd Jay' is the reason why I decided to take this journey. He makes robots that he takes with him by attaching them to his coat. He uses a combination of 3D printers and development boards to make his companion bots and often leaves guides on hackster with a guide describing how to make them yourself.

Twitter: @Odd_Jayy
Instagram: @odd_jay
Hackster: Jorvon Moss
Personal favourite: Asi (Anansi) Robot Companion

Helen Leigh
Helen Leigh is a technical writer and maker who creates art by using electronics innovative ways. From stitching electronics on fabric with conductive thread to DIY musical instruments she explores whatever is on her mind and shares it with the world. Through her book she learns kids and beginners to mix electronics and crafts.

YouTube: Helen Leigh
Twitter: @helenleigh
Instagram: @helenleigh_makes
Github: @helenleigh
Hackaday: @helenleigh
Personal favourite: WIP arduino uno with conductive thread

TwinkleTwinkie
TwinkleTwinkie is a PCB artist that makes and sells a lot of badges that can be worn. He posts a lot of designs on on Hackaday and reveals how he achieves certain effects. He also has a few lectures and demos on his youtube channel for those who want to learn how to build their own.

YouTube: Twinkle Twinkie
Twitter: @mrtwinkletwink
Hackaday: @TwinkleTwinkie
Hackster: TwinkleTwinkie
Personal favourite: Understanding & Making PCB Art

Jiří Praus
Jiří Praus is a maker that builds beautiful freeform PCBs by soldering wires and components to each other. The have a beautiful almost modern steampunk like look.

YouTube: Jiri Praus
Twitter: @jipraus
Instagram: @jiripraus
Github: @jpraus
Hackaday: @georgus
Hackster: Jiří Praus
Personal favourite: Brass LED heart badge

Thanks for scrolling

Seriously! Hopefully, this is a preview that made you at least aware of the existence of embedded systems. Embedded development is something I am really interested in right now so don't be surprised if you see more posts about electronics and microcontrollers 😄

Audio visualization with Rust

Maniflames — Sat, 22 Jun 2019 17:00:40 +0000

Since the start of this year I have been very determined to learn more about rust. I knew I wanted to do something with audio but had no idea where to start. Thankfully Justin Wernick created Rusty Mic and wrote a blogpost about it. I decided to build my own simple 'microphone visualization' with a different graphics library. If you catch something that could be improved let me know, I'd love to learn!

If you just want to check out the code you can check out the repo I made for this small project:

maniflames / MicViz

A simple real time audio visualisation application build in Rust.

MicViz

A simple real time audio visualisation app build in Rust.
This is just a small and simple thing implemented with (rust) portaudio and three(-rs).

Getting started

Environment setup

You should be able to compile this project for any OS. For now this docs will focus on how to setup the enviroment on MacOS.

To setup the environment run the following commands (not everything may apply to you):

# Clone this repository
git clone https://github.com/maniflames/MicViz.git

# Install Rust with homebrew
brew install rust

# Install portaudio with homebrew
brew install portaudio

# Unpack MacOS SDK headers 
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

Compile and Run

Now that you're all set you can run this:

# Navigate to project
cd MicViz

# Compile and run with cargo
cargo run

Enjoy 😁

View on GitHub

Dependencies

For this project I'll be using two crates: portaudio for working with audio and three. So go ahead and put the following in your Cargo.toml:



[dependencies]
portaudio = "0.7.0"
three = "0.4.0"

Usually that would be all you'd have to do but in this case things are a little different. The portaudio crate just consists of Rust bindings to an actual installation of portaudio so you'll have to install that yourself. You can download and compile portaudio for Windows, Linux and MacOS. However if you happen to dev on a mac it's probably easier to install it through homebrew with pkg-config.



brew install pkg-config
brew install portaudio

Reading audio input

Let's read input from the default mic of your computer first. To accomplish this with portaudio's non-blocking inputstream. I'll try to be clear as possible by just commenting code line by line.



use portaudio;
use std::sync::mpsc::*;

fn main() {

    // Construct a portaudio instance that will connect to a native audio API
    let pa = portaudio::PortAudio::new().expect("Unable to init PortAudio"); 
    // Collect information about the default microphone
    let mic_index = pa.default_input_device().expect("Unable to get default device");
    let mic = pa.device_info(mic_index).expect("unable to get mic info");

    // Set parameters for the stream settings.
    // We pass which mic should be used, how many channels are used,
    // whether all the values of all the channels should be passed in a 
    // single audiobuffer and the latency that should be considered 
    let input_params = portaudio::StreamParameters::<f32>::new( mic_index, 1, true, mic.default_low_input_latency);

    // Settings for an inputstream.
    // Here we pass the stream parameters we set before,
    // the sample rate of the mic and the amount values we want to receive
    let input_settings = portaudio::InputStreamSettings::new(input_params, mic.default_sample_rate, 256);

    // Creating a channel so we can receive audio values asynchronously
    let (sender, receiver) = channel(); 

    // A callback function that should be as short as possible so we send all the info to a different thread
    let callback = move |portaudio::InputStreamCallbackArgs {buffer, .. }| {
        match sender.send(buffer) {
            Ok(_) => portaudio::Continue, 
            Err(_) => portaudio::Complete
        }
    };

    // Creating & starting the input stream with our settings & callback
    let mut stream = pa.open_non_blocking_stream(input_settings, callback).expect("Unable to create stream"); 
    stream.start().expect("Unable to start stream");

    //Printing values every time we receive new ones while the stream is active
    while stream.is_active().unwrap() {
       while let Ok(buffer) = receiver.try_recv() {
            println!("{:?}", buffer); 
       }
    }
}

Running this should look something like this:

Visualizing the audio

If you look closely you'll notice that all you get back from your microphone is a slice containing numbers between -1.0 and 1.0. These numbers are a representation of how sound waves have manipulated a moving part within your microphone over time. There are different ways to visualise this change but to keep it simple let's draw a line for every change that occurs in time. We'll animate the lines by simply removing them and drawing new lines when we receive new changes.



use portaudio;
use std::sync::mpsc::*;
use three;

//struct for storing the application state
#[derive(Debug)]
struct State {
    sound_values: Vec<f32>,
    scene_meshes: Vec<three::Mesh>
}

fn main() {
    // Receiving audio input 
    let pa = portaudio::PortAudio::new().expect("Unable to init PortAudio"); 
    let mic_index = pa.default_input_device().expect("Unable to get default device");
    let mic = pa.device_info(mic_index).expect("unable to get mic info");

    let input_params = portaudio::StreamParameters::<f32>::new(mic_index, 1, true, mic.default_low_input_latency);
    let input_settings = portaudio::InputStreamSettings::new(input_params, mic.default_sample_rate, 256);

    let (sender, receiver) = channel();

    let callback = move |portaudio::InputStreamCallbackArgs {buffer, .. }| {
        match sender.send(buffer) {
            Ok(_) => portaudio::Continue, 
            Err(_) => portaudio::Complete
        }
    };

    let mut stream = pa.open_non_blocking_stream(input_settings, callback).expect("Unable to create stream"); 
    stream.start().expect("Unable to start stream"); 

    // Create a full screen window with a black background
    let mut builder = three::Window::builder("My Mic"); 
    builder.fullscreen(true); 
    let mut win = builder.build(); 
    win.scene.background = three::Background::Color(0x000000);

    // Create a variable that will contain the state off the app
    let mut state = State {
        sound_values: Vec::new(),
        scene_meshes: Vec::new()
    };

    // Create a camera that will be put in the scene on location 0.0, 0.0
    let camera = win.factory.orthographic_camera([0.0, 0.0], 1.0, -1.0 .. 1.0); 

    //Animation loop that will run until you press ESC or exit the program
    while win.update() && !win.input.hit(three::KEY_ESCAPE) {
        // Put new lines in the scene temporarily save them in the state
        update_lines(&mut win, &mut state);
        // Show the lines
        win.render(&camera);
        // Remove all lines from the scene and the state
        remove_lines(&mut win, &mut state);

        //Update state
        while let Ok(buffer) = receiver.try_recv() {
            update_sound_values(&buffer, &mut state); 
       }
    }
}

// Pass new samples into the state by overriding the vector
fn update_sound_values(samples: &[f32], state: &mut State) {
   state.sound_values = samples.to_vec(); 
}

// Put new lines in the scene temporarily save them in the state
fn update_lines(win: &mut three::window::Window, state: &mut State) {
    for (index, y_position) in state.sound_values.iter().enumerate() {

        // calculate the x position of the line by calculating a normalized x position between 0.0 and 1.0 (i / num_samples)
        // With the scale variable the size of the visualization can be changed. 
        let i = index as f32; 
        let num_samples = state.sound_values.len() as f32; 
        let scale = 3.0; 
        let x_position = (i / (num_samples / scale)) - (0.5 * scale);

        // create the geometry for a line with the calculated positions
        // three is a 3D graphics library so we pass the x, y, z values
        let geometry = three::Geometry::with_vertices(vec![
            [x_position, y_position.clone(), 0.0].into(),
            [x_position, -y_position.clone(), 0.0].into()
        ]);

        // create material so for our line, in this case white line material
        let material = three::material::Line {
            color: 0xFFFFFF,
        };

        // create a 3D object from the geometry and the material
        let mesh = win.factory.mesh(geometry, material);

        // Put the line in the scene and store it in the state
        win.scene.add(&mesh); 
        state.scene_meshes.push(mesh); 
    }
}

// Remove all lines from the scene and the state
fn remove_lines(win: &mut three::window::Window, state: &mut State) {
    for mesh in &state.scene_meshes {
        win.scene.remove(&mesh); 
    }

    state.scene_meshes.clear(); 
}

If you run the script it should look something like this:

Enjoy your MicViz, if you have some time on your hands show off your version of it 😄👀

And again, let me know any way to improve presented code if you happen to know a thing or two about Rust!

Pointcloud effect in Three.js

Maniflames — Sat, 25 May 2019 23:58:49 +0000

Not too long ago I built a site that served as a submission for a small competition. To spice it up, I decided to add some Three.js. An effect that has been on my mind for a pretty long time was the pointcloud. Austin Mayer has implemented a really cool one with effects on his website and I've been thinking about since I've seen it on his site.

// Detect dark theme var iframe = document.getElementById('tweet-1098662776929693706-0'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1098662776929693706&theme=dark" }

Since the site had a little more to it, I decided to implement a super basic version of a pointcloud. Three.js provides a few functions that enable you to create a pointcloud pretty quickly.

Points instead of Mesh

A mesh (3d object) in Three.js consists of geometry and material. But instead of showing an entire mesh you just want to show the vertices. The Points class in Three.js can take a geometry and display points instead of the 'full' object. With PointsMaterial you are able to control the size of your points. The code for a 'pointcloud mesh' looks something like:



  let geometry = new THREE.TorusGeometry(10, 3, 16, 100)
  let material = new THREE.PointsMaterial({ color: 0xFFFFFF, size: 0.25 })
  mesh = new THREE.Points(geometry, material)

  scene.add(mesh)

For the full code, click/press on the example and check out main.js in the code tab!

Using 3D models

It's possible to load 3D models in Three.js but you have to put in a little extra work. Depending on the format of the 3D model you have to load a loader in addition to the main library. I love to use .obj models myself so I personally need the OBJLoader.

If you load the library through an HTML tag you have to add an extra tag that loads a seperate script that comes with the Three.js download. This script can be found in examples/js/loaders/OBJLoader.js.

If you have included the entire folder loading it will be kind of like:



<script src="three/examples/js/loaders/OBJLoader.js"></script>

If you use npm, you can import the loader through the jsm folder. Keep using the js folder if you prefer the require syntax though! The import statements look something like this:



//import syntax
import { OBJLoader } from 'three/examples/jsm/loaders/OBJLoader.js'

//require syntax, require adds OBJLoader directly to THREE
require('three/examples/js/loaders/OBJLoader.js')

Loaders work a bit like an extend 'fetch' without promises. You insert a url of the file containing the model, the loader will execute a http request. You provide callbacks for a successful request, a request that is still in progress and an unsuccessful request.

You can get the geometry of the object you loaded by selecting the first child's geometry of the result.



const loader = new THREE.OBJLoader()
loader.load('https://cdn.glitch.com/fcf3c007-b4eb-4250-ba6b-653fdab94ce3%2Fjapanese_temple.obj?1558792651869',
(obj) => {
    // the request was successfull
    let material = new THREE.PointsMaterial({ color: 0xFFFFFF, size: 0.25 })
    mesh = new THREE.Points(obj.children[0].geometry, material)
    mesh.position.y = -15 //this model is not exactly in the middle by default so I moved it myself
    scene.add(mesh)
},
(xhr) => {
    // the request is in progress
    console.log(xhr)
},
(err) => {
    // something went wrong
    console.error("loading .obj went wrong, ", err)
})

Small disclaimer: 3D models can be build in 3D modeling software like Autodesk Maya3D and Blender with geometry and 'modifiers'. If a very big part of the model is created with modifiers the points won't show up in a way you can 'see' the object when you apply the pointcloud. That's why it's very important that you always test 3D models you want to use specifically for this purpose.

A little control

Interactivity will always make something a lot more fun. Hover and morph effects like on Austin Mayer's site definitely take effort and time to create. But three has functionality you can quickly add to at least give users the ability to move the camera around with OrbitControls. Like 3D model loaders the controls are an extension you have to load. Orbit controls are located in examples/js/controls/OrbitControls.js (or examples/jsm/controls/OrbitControls.js using the import syntax). The code looks a little like this:



 camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000)
  camera.position.z = 40

  const controls = new THREE.OrbitControls(camera)
  controls.enableZoom = false //zoom happens on scroll which can be quite annoying

I hope this helps as a 'getting started' on creating pointclouds in Three.js!

Credits

I got a lot of moral support from my best friend Sven, who also submitted a website to compete. I had a lot of doubt and wasn't sure wether I should submit anything at all. I'm glad he convinced me, because we are both be in Shanghai this winter 🎉. In case you want to know a little more, he wrote an article a while ago:

Why I Struggled with Creating an Account Here and Why I Did It

Sven Hoffmann ・ Feb 7 '19

#writing #beginners #career #meta

Tricks I learned to improve my communication

Maniflames — Sun, 03 Feb 2019 21:26:59 +0000

This was my final week as intern at UpReach and I had a blast! Working on the front-end, back-end and even a hardware component of the UpReach photo booth taught me a lot. The most exciting thing however, was that I got to live in Berlin for five months. However working in another country can have its downsides, like language barriers. English was the go to language even though not a single person, including me, was a native speaker. This was specifically because I could read a bit of German but not speak it. On top of that I often had to talk to project management and sales who did not always know the details of the technology behind the product. There are four tricks that improved my communication towards my co-workers and I would really like to share them with you.

1. Keep track of the conversation

The photo booth business is fast. From time to time I had to join briefings that discussed special configurations and development for specific clients. A lot of information would be thrown at me in a very short period of time. By writing down important details and keywords during the briefing I was able to keep track of the conversation. This trick sounds like the obvious thing to do, but it will surprise you how easy it is to forget to take notes. Taking notes does not just help you in the moment but also in the long run. Small details that make a big difference will slip your mind at some point, reading notes from the past can really help.

2. Delay your opinions

If you have experienced certain patterns over and over it is very easy to jump to conclusions. Before you do so make sure you receive all of the information that has to be communicated. Something that seems like a minor detail to the project manager can make a big difference to what you have to build. Someone might also come with a proposed solution that doesn't seem to fit the situation. Before you decide to implement something 'better' instead ask why the person proposed it. Nodding your head and doing what you think is right or faster can backfire and cost you a lot more time. Always make sure you understand the full context. Communicate concerns and alternatives when you have an understanding the bigger picture.

3. Explain tech on the right level of complexity

Tailor your explanation to the audience whenever you have to explain the technical side of things. As developer, it is easy forget how many acronyms and abstractions you encounter on a daily basis. If you are talking to someone who is not a developer you will most likely have to tone down the jargon. Make sure the amount of jargon and technical detail suits the person you are talking to. It often takes time to figure out how comfortable someone is with details. Some project managers at UpReach preferred to stay as far away from the jargon as possible. Others knew a lot about tech and could understand me with ease. It will be a lot easier to talk to different departments if you are able to explain yourself with different levels of complexity.

4. Make sure everyone is on the same page

Assuming that everyone is on the same page right before a briefing ends is a huge mistake. It is very easy to forget or misinterpret something. Before you collectively end the brief, summarize the important conclusions out loud and ask anything is missing. After everyone agrees, state what each person is going to do from this point on. This saves a lot of time and miscommunication in the long run.

Clear communication is a really important part of a job in any field. Hopefully, these four tricks will clear up some communication with co-workers. I still have to get 'good' at all of these but just trying can already make a big difference.

What are your favourite communities?

Maniflames — Sun, 27 Jan 2019 17:31:56 +0000

By posting and interacting with others on DEV for the past month I have learned a lot. Not just about code or productivity but about how awesome community can be. Everyone on DEV helps others out while staying polite which is really cool. In pretty much every community I'm just a lurker who passes likes every once in a while. This is the first community that made me feel I could post things myself and be part of a conversation.

I realised a lot of DEVs have a twitter account. In the back of my mind I knew there are some developers on twitter and followed a few. After starting out with devs on here and exploring from there I fell into a rabbit hole of a tons of communities and people that use twitter, email lists, personal blogs and sites like dev to share knowledge. I feel like I've just scratched the surface of interesting people and communities to check out.

What are your favourite communities and/or devs and why? I'd love to discover even more awesomeness 😁

For anyone who is looking for a nice chat with other beginners: This discuss post resulted in a telegram group 🎉. Join in t.me/randomdevs !

Creating a custom shader in Three.js

Maniflames — Mon, 21 Jan 2019 00:03:29 +0000

3D stuff in the browser is awesome. After playing around with threejs for some time and making a mini-game at school I started to like it a lot. A classmate that is really into graphics programming told me a little bit about WebGL and shaders. It seemed really cool and I promised myself I would make my own shader. Of course some other shiny thing caught my attention and I forgot about it but, from today on I can finally say that I have created a shader and used it within threejs.

Three JS

Before going all in on shaders it is probably a good idea to explain what three js is. Threejs is a javascript library to ease the process of creating 3D scenes on a canvas. Other popular solutions like a-frame and whitestorm js are build on top of it. If you have ever played around with those but want even more control definitely try it out! (If you are a TypeScript lover, three js has type definitions 😉).

The most popular intro to this library is creating a cube and making it spin. There is a written tutorial in the threejs documentation and a brilliant youtube tutorial by CJ Gammon that is part of his 'diving in: three js' series.

Creating this cube is a basically preparing a film set and placing it inside of that set. You create a scene and a camera and pass these to a renderer to say: "hey this is my movie set". Then you can place mesh, which is basically an object, within the scene. This mesh consists of a geometry (the shape of the object) and a material (the color, behavior towards light and more). Based on the material you have chosen, you might want to add different kinds of lights to the scene. In order to animate the object and actually display everything you create a loop. Within this loop you tell the renderer to show the scene. Your code might look like this:


window.addEventListener('load', init)
let scene
let camera
let renderer
let sceneObjects = []

function init() {
  scene = new THREE.Scene()

  camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000)
  camera.position.z = 5

  renderer = new THREE.WebGLRenderer()
  renderer.setSize(window.innerWidth, window.innerHeight)

  document.body.appendChild(renderer.domElement)
  adjustLighting()
  addBasicCube()
  animationLoop()
}

function adjustLighting() {
    let pointLight = new THREE.PointLight(0xdddddd)
    pointLight.position.set(-5, -3, 3)
    scene.add(pointLight)

    let ambientLight = new THREE.AmbientLight(0x505050)
    scene.add(ambientLight)
}

function addBasicCube() {
  let geometry = new THREE.BoxGeometry(1, 1, 1)
  let material = new THREE.MeshLambertMaterial()  

  let mesh = new THREE.Mesh(geometry, material)
  mesh.position.x = -2
  scene.add(mesh)
  sceneObjects.push(mesh)
}

function animationLoop() {
  renderer.render(scene, camera)

  for(let object of sceneObjects) {
    object.rotation.x += 0.01
    object.rotation.y += 0.03
  }

  requestAnimationFrame(animationLoop)
}

Shaders

Shaders are basically functions or small scripts that are executed by the GPU. This is where WebGL and GLSL (OpenGL Shading Language) come into play. WebGL is a browser API that allows javascript to run code on the GPU. This can increase the performance of certain scripts because your GPU is optimized for doing graphics related calculations. WebGL even allows us to write code that will be executed directly by the GPU in the GLSL language. These pieces of GLSL code are our shaders and since threejs has a WebGL renderer we can write shaders to modify our mesh. In threejs you can create custom material by using the 'shader material'. This material accepts two shaders, a vertex shader and a fragment shader. Let's try to make 'gradient material'.

Vertex Shader

A vertex shader is a function that is applied on every vertex (point) of a mesh. It is usually used to distort or animate the shape of a mesh. Within our script it looks something like this:

function vertexShader() {
  return `
    varying vec3 vUv; 

    void main() {
      vUv = position; 

      vec4 modelViewPosition = modelViewMatrix * vec4(position, 1.0);
      gl_Position = projectionMatrix * modelViewPosition; 
    }
  `
}

The first thing that you probably notice is that all our GLSL code is in a string. We do this because WebGL will pass this piece of code to our GPU and we have to pass the code to WebGL within javascript. The second thing you might notice is that we are using variables that we did not create. This is because threejs passes those variables to the GPU for us.

Within this piece of code we calculate where the points of our mesh should be placed. We do this by calculating where the points are in the scene by multiplying the position of the mesh in the scene (modelViewMatrix) and the position of the point. After that we multiply this value with the camera's relation to the scene (projectionMatrix) so the camera settings within threejs are respected by our shader. The gl_Position is the value that the GPU takes to draw our points.

Right now this vertex shader doesn't change anything about our shape. So why even bother creating this at all? We will need the positions of parts of our mesh to create a nice gradient. By creating a 'varying' variable we can pass the position to another shader.

Fragment shader

A fragment shader is a function that is applied on every fragment of our mesh. A fragment is a result of a process called rasterization which turns the entire mesh into a collection of triangles. For every pixel that is covered by our mesh there will be at least one fragment. The fragment shader is usually used to do color transformations on pixels. Our fragment shader looks like this:

  return `
      uniform vec3 colorA; 
      uniform vec3 colorB; 
      varying vec3 vUv;

      void main() {
        gl_FragColor = vec4(mix(colorA, colorB, vUv.z), 1.0);
      }
  `
}

As you can see we take the value of the position that was passed by the vertex shader. We want to apply a mix of the colors A and B based on the position of the fragment on the z axis of our mesh. But where do the colors A and B come from? These are 'uniform' variables which means they are passed into the shader from the outside. The mix function will calculate the RGB value we want to draw for this fragment. This color and an additional value for the opacity are passed to gl_FragColor. Our GPU will set the color of a fragment to this color.

Creating the material

Now that we've created the shaders we can finally build our threejs mesh with a custom material.

function addExperimentalCube() {
  let uniforms = {
        colorB: {type: 'vec3', value: new THREE.Color(0xACB6E5)},
        colorA: {type: 'vec3', value: new THREE.Color(0x74ebd5)}
    }

  let geometry = new THREE.BoxGeometry(1, 1, 1)
  let material =  new THREE.ShaderMaterial({
    uniforms: uniforms,
    fragmentShader: fragmentShader(),
    vertexShader: vertexShader(),
  })

  let mesh = new THREE.Mesh(geometry, material)
  mesh.position.x = 2
  scene.add(mesh)
  sceneObjects.push(mesh)
}

This is where everything comes together. Our 'uniforms' colorA and colorB are created and passed along with the vertex shader and fragment shader into the shader material. The material and geometry are used to create a mesh and the mesh is added to the scene.

I build this in glitch. A friend recommended it and it is great! Some add blockers block you loading the embed though, so here is a direct link just in case.

The left cube is a cube using mesh lambert material, the right cube uses our own 'gradient material'. As you can see our material looks pretty sweet but ignores the light settings in the scene. This is because we didn't do the math in our fragment shader to take the light into account. This is hopefully something I figure out soon 😝.

Resources

It took some time to figure this out and if you liked this you should really check out the sources I have used to learn and understand this:

How do you approach knowledge gaps?

Maniflames — Sun, 13 Jan 2019 23:08:46 +0000

It's normal to get stuck from time to time when you are trying to build something. However, when I make the same mistake again and again I know it has to do with my lack of knowledge about a topic.

When it is a framework or library specific to problem the answer is most likely in the docs, on stack-overflow or in a tutorial. However when it has to do with build in language features or theoretical knowledge it can be harder to spot what you don't know. To be fair I bump into the right information when I need it by accident. It's usually hidden in a talk or a well written article or post.

Two real life examples of the 'problem' I'm talking about:

1. Understanding JS

When I stared using a lot more asynchronous JS the expectation vs reality of what I was trying to write did not always match. Some tinkering or workarounds would usually solve the problem. It wasn't until a very enthusiastic JS dev advised me to watch a talk on the event loop that I realized what a gap in my knowledge was. I had no idea how JS handled async operations under the hood and why some things wouldn't work.

In case you haven't seen it and you like JS check out "What the heck is the event loop anyway" by Philip Roberts. He talks about a lot more than just async programming, a lot of JS related buzzwords will make sense after hearing this talk.

2. Understanding Rust

Something I'm struggling with right now is ownership and borrowing in Rust, even though the book has an entire chapter on it. It basically has to do with the memory used by your code and whether you try to use the real value, a reference or a copy.

I frequently fight with the borrow checker when I try to do something in Rust. After some practice I started to get a little bit better and can at least understand why I am stuck. I ran into this post and if you happen to struggle with ownership this one will really help.

Article No Longer Available

To be fair most things related to memory in Rust are a problem to me right now because I don't know that much about it. I guess that is the thing I'll have to understand at least a little bit better to truly understand what I'm doing.

How do you reveal what the gaps in your knowledge are? Do you have a favorite method for learning something more theoretical and applying it? I'd love to hear from other dev's how they deal with this 😄.

~ Happy Coding :)

How conventional commits improved my git skills

Maniflames — Sun, 06 Jan 2019 21:50:58 +0000

At the moment of writing this I’m in the final month of my internship. I am slowly realising how much I have learned in the past few months. But of all the things I have learned, a better understanding and usage of git is one of the thing that had the biggest impact. Whenever I pushed my changes before this internship I would do something like this:

git add .
git commit -a -m “added a few features” 
git push

And that’s it. I would usually do this at the end of the day or whenever I didn’t want to lose progress. However in this company I picked up the habit of committing in a standardised structure called conventional commits.

How it works

Instead of ‘just’ writing your message you follow a template that looks like this:

<type>[optional scope]: <description>

[optional body]

[optional footer]

Every commit has a type that falls into a predefined category, at this company the specific categories are:

feat: a feature that is visible for end users.
fix: a bugfix that is visible for end users.
chore: a change that doesn't impact end users (e.g. chances to CI pipeline)
docs: a change in the README or documentation
refactor: a change in production code focused on readability, style and/or performance.

The scope specifies what you have changed, preferably in a single word.
The description is a one liner that specifies what the change is. You can use the body in case there is more information that should be in the commit message. Finally, there is a footer where you tag relevant issues or pull requests.

An example of a 'conventional commit':

git commit -m "feat(ratings): added the ability to add star ratings to posts.

This has been a feature requested by different users. 
Changes in the database structure where necessary to make this happen. 

closes #105"

Using this commit structure has impact on how I use version control on a daily basis and on the 'quality' of my commit messages.

1. More descriptive commits

I think the most obvious change is that my commits where a lot more descriptive than before. By providing a type and scope it is often a lot more obvious where changes can be found before even looking at the files that are part of the commit. This also allows the description to focus on what changed since other details are known already. Even though the body and the footer are optional they are extremely useful for the future. For instance a body that describes how a certain bug was fixed and to which issue it referred can be very helpful when it turns out that the fix unintentionally caused a change in behavior of other features later on.

2. A change in workflow

When using conventional commits I can't just collect all the changes I have made in a single commit. I have to take my time and think about what I have done in the first place. Based on that I start commit my work. For example, I still edit the docs straight away when I add an important feature or change the CI pipeline. Instead of committing everything in one go I stage certain files and write the appropriate commit message. This feels like a lot of work in the beginning but again when things go wrong or not as expected it is a lot easier find out when the change happened from a version control perspective.

3. Using more git features

Besides of 'proper' staging there are a lot more git features that I use. To be fair this is also because of other aspects of the git workflow (separation of production and development code in different branches). Rewriting a commit message or deleting my last local commit are some things I didn't do before.

There are more benefits of using this commit structure. One of many is that clear changelogs can be generated by tools and the use of certain keywords triggers some cool features in repository hosting solutions like Github and Bitbucket. The best way to get to know git is by using it. I have to admit that I did mess up here and there when trying out new things. I really recommend the git flight rules repository in case something goes wrong or you’re not entirely sure of how to do something.

Hopefully you’re willing to try out conventional commits yourself.
~ Happy coding :)