ganonm

As you can see from the table on my GitHub page, progress was slow and took several weeks to reach baseline levels. This was from maybe 45-60mins per day of dedicated practice. I see the time investment as having paid for itself tenfold already.

Here is a link to my keyboard layout which you can freely use. It is optimised for Vim and Ubuntu use.

https://github.com/Ganon-M/ergodox-vim-ubuntu

Launched this a few months ago. I've made about $14 a month. In terms of return on investment I would have been better picking up pennies in the street, but it was a fun side project. Also, haven't done any real marketing yet... All sales have been organic discoveries through Unity store.

To make an analogy, it is as if you had an elastic sheet with objects moving on its surface. The elastic sheet can be expanded which causes the distance between any two fixed points to grow.

(it's been many years since I studied physics so any corrections to my comments are appreciated)

I bought a Dell XPS13 laptop recently which unfortunately had a non functioning motherboard. I contacted Dell and a technician came to my house first thing the next day and replaced it, no questions asked. Totally hassle free. I'd take that any day over having to book an appointment to see a 'Genius'.

The system I ended up building allowed users to monitor the robot from the cloud, including telemetry such as end effector sensors and axis positions, as well as uptime. It also allowed steaming tool paths from the web platform to the robots directly with appropriate safety measures such as manual intervention required to start it. Would love to generalise this sort of thing and create a turnkey solution that allowed people to focus on solving their actual robotics problems, not spend all their time glueing together disparate components.

First thing to really wrap your head around is 'what is a GameObject'. A GameObject is just an entity that exists at runtime in the game world and has things called 'Components' attached to it. The simplest possible GameObject has only one component, called a Transform. This is simply a stateful record of the GameObject's position, rotation and scale. You can expect to write lots of code that involves manipulating Transforms.

There are components for everything. Want your GameObject to have a visual manifestation in the game world? Add a MeshRenderer component. Want to allow it to obey the laws of Newtonian physics? Add a Rigidbody component.

You can expect to spend a lot of your time implementing your own components. These custom components will often, ultimately just end up manipulating the transforms and other components of other GameObjects in the world.

Now you might wonder how GameObjects are created. One way is just to create an individual GameObject and attach components to it (analogous to an anonymous class), for the most part however, you will create things called 'prefabs' which are analogous to classes in OOP. Instances of these prefabs can then be easily instantiated (either manually via the editor or programmatically at runtime).

Once you have gotten your head around these core concepts, the rest starts to naturally follow. You can study topics like animation, custom shaders, net code, physics etc. and quickly understand how they relate to the core concepts.

My path to learning Unity (and I'm still learning!) was to follow the Unity official tutorials then start prototyping game mechanics - how to create a first person controller, how to allow player to interact with game world objects, how to animate characters etc. I'm now at I guess an 'advanced beginner' stage. I'm comfortable with the core API, have dabbled in most of the common topics you would need to be familiar with to make a game, and now I'm just doing projects to build up my productivity and skills.

Regarding the development environment, yes it's very integrated and isolated. For me this was a bit of a culture shock as I generally prefer working with text rather than IDEs, but I've gotten fairly well acclimatised to it now.

I am currently awaiting approval to sell an editor plugin on the Unity store which I spent some free time working on as a side project. In game level design, most artists make use of 'modular' assets to some extent. These are small sections of a structure e.g. a corner wall section or a roof section, which can be combined together to make endless variations on a building style. The plugin I made allows you to specify 'sockets' on each modular asset, including a type and compatibility system, then it handles automatic snapping together of assets in the editor. This speeds up a assembly of modular assets significantly. The alternative, old fashioned way of doing this is 'vertex snapping' which is tedious and time consuming.

Video here: https://youtu.be/MvYTbIU1d-c

This is incorrect (probably a typo) - the GFC ensures there is a very low resistance path to source, which ensures a current spike that is sufficient to blow the fuse.

The London - Edinburgh sleeper train (Caledonian Express) has been running pretty much since 1873 and is an amazing way to get between the two cities. You arrive at the station in London between 10-12pm, depending on if you want to have a few snacks or glasses of wine, then wake up in Edinburgh around 8am the next day.

The workspaces are laid out in a grid (e.g. 4x4) so you naturally adopt a convention for where you place applications. For me, I have browsers and desktop apps along the bottom, terminals and IDEs along 2nd row and then GVim instances in the remaining top two rows. I can almost instantaneously switch between any window I like.

I like this setup so much that when I was using MacOS for a brief period, I installed TotalSpaces2 which emulates Ubuntu style workspaces.

The man from mars concludes that this person must be a slave.

I went through 20 iterations to find a layout optimised for using Vim in Ubuntu - feel free to check it out.

https://github.com/Ganon-M/ergodox-vim-ubuntu

When he talks about state for example, I assume he means mutable state. Everyone knows this is best avoided if possible. The vast majority of OO languages provide mechanisms to avoid mutability e.g. data classes or keywords to make references constant.

He also rails against private state specifically. I assume again that he means private mutable state. This is generally a bad idea and is accepted pretty uncontroversially as a bad idea. The principle of data hiding in general however is definitely not a bad idea. Being able to enforce scoping rules on classes/functions/members is not meant to facilitate creating 'black box' entities whose internal mutations are difficult to reason about, but is instead meant to provide guarantees about dependencies between different parts of a system, i.e. Separation of Concerns.

Regarding 'everything is an object', in many cases this is perfectly acceptable as it guarantees some sort of basic interface that all entities conform to e.g. being able to ask an entity to provide a hash code, or to carry out a comparison check with some other entity. Some modern languages like Kotlin even eschew the concept of primitives altogether and just make everything an object.

Finally, regarding his point about OO languages having data type definitions all over the place, I must be misunderstanding something here... Why on Earth would you want all your data type definitions in one place?

Anyway, just wanted to give my $0.02 lest anyone get the impression that these are 'knockout punches' against any and all OO languages.

The main advantage (just picking reasons off the top of my head) is that you can write your code as if it will certainly succeed, then have a separate block of code for handling failure cases. This makes code a lot more legible and draws explicit attention to failure case handling. Some languages make a distinction between 'checked' and 'unchecked' exceptions (e.g. Java) whereby checked exceptions must be handled at the call-site, whereas unchecked exceptions can be caught anywhere in the call stack (or not at all, in which case the thread or program will terminate). It is often conventional to forego checked exceptions and only use unchecked exceptions to provide flexibility to the caller in where they handle the exception. Some languages such as Kotlin remove the concept of checked exceptions from the language entirely.

Languages like C which don't have exception handling force the programmer to use return code checking to verify if a method call has succeeded. This is fine, but as I alluded to above, can add noise to code and diminishes flexibility.

One example of the power of unchecked exceptions is e.g. an exception mapper in a REST server. This allows the programmer to throw an unchecked exception at any point in the server application code and this will (if not handled by the application code explicitly) get caught by the exception mapper. It will then map this exception to an appropriate HTTP response code and return it to the API user.

An argument against exceptions is that there is a large 'overhead' to handling them. I've yet to see a scenario where an application performance bottleneck is being caused by exceptions. YMMV.

Now, these expressions don't imply it's impossible for the angle (theta) and angular momentum (L) both to be simultaneously zero, just that it's infinitely improbable. If you plug in reasonable values for both parameters, say by assuming that Δtheta = ΔL = sqrt(hbar) and that the actual values took a figure corresponding to an expected value assuming these uncertainties, you can work out that the pencil will actually fall over in a few seconds.