101–110 of 222 posts
Electronics, lighting, sensors, display tech.
What are your favorite resources for learning about these things?
2. GraphQL - Typed, structured API.
3. https://en.wikipedia.org/wiki/Attachment_theory: A very powerful tool to explain human behavior. It can explain individual personal interactions, personal and professional relationships, family systems and many bigger picture things.
4. How to build desktops: Build times are way way faster on desktop CPUs. More control over motherboard / getting faster IO, further improving buildtimes. More upgradeable, things can be switched out, whereas with laptops everything is soldered together.
5. Language practice: Started tapes on Polish / Ukrainian. Restarting Chinese soon.
6. Basic fitness things / more exercises
In the past eight months, I studied React and ElasticSearch but never did any projects at work or on my own so neither went anywhere. However, I did put my first two Node projects in production and did a Fargate (AWS Serverless Docker) proof of concept that I’m trying to find time to put into production. I want to get deeper into Docker.
Also, last spring I took the basic Electronics 101 class at our local community college (http://www.ccsf.edu/en/educational-programs/school-and-depar...) -- Ohms law, intro to RC time constants, transformers, etc. It was just one night a week, so not a huge time commitment (2.5 credit units). This semester: active analog circuits!
Not sure it's made me any better at my Python/SQL day job, but perhaps more methodical.
Out of curiosity, how did you get started with distributed systems side projects? Do you use e.g. a bunch of Docker containers or cloud VMs?
In no particular order:
https://github.com/GoogleContainerTools/skaffold
Outside of Tech, Japanese. Really love watching Anime in my down time. In the past I have watched well over 100+ series in Dub. Recently I was frustrated waiting for Dub for some later series and newer ones. Which lead me to watch Subs and I really dislike reading the text, especially when two characters are talking you have text on the top and bottom of the screen! Too much to read at once. Finally many times there…
I've spent this year mostly on Go. I think I'm in a maybe good enough spot to be employable with it? Which was probably my goal all along. Through Go, though, I've been feeling like picking up a language with a more advanced type system. Usually when I have that feeling I get trapped in analysis paralysis and just never pick anything up. I've been considering just hard-committing to Java/the JVM and taking it as it i…
* Rust is often thought of as occupying a similar niche to Go, because it can deploy single native binaries and has pretty high-level abstractions. Often known for slow compile times, though.
* OCaml has one of the best type systems and compilers out there, with almost full type inference and also compiles to pretty efficient native binaries. Compiler is known to be fast.
* D is also an established, fast and efficient compiler, a powerful language with good libraries and tooling.
* You could definitely try out Haskell, it is pretty mainstream nowadays and there are lots of great learning resources.
Earlier quoted context omitted.
Take a look at Kotlin. We are building our enterprise products with it. You get all the benefits of Java (stability, maturity) without the bad parts (boilerplate, boredom). We just hired a Kotlin person (really a Java guy who refreshed his Kotlin over the weekend) for this, and we may be hiring more. I suspect more companies will start looking at Kotlin in the next 2-3 years, especially for green field projects.
The concern I have with JVM languages is that employers will have a constant temptation to just fall back into Java instead of actually committing to the language they've chosen. From what I understand, Kontlin/Scala/Clojure all have relatively easy Java-interop, so it smells like after a while non-Java projects could just become Java projects? I have heard lots about Kotlin though, and it sounds like most devs that'…
I have noticed something like what you describe with Groovy though. We've had groovy enthusiasts that have peppered our java codebases with Groovy. It's not viral or contagious, and ultimately just served to confuse matters and make the code harder to understand. We've had more than a couple of refactor efforts to get rid of groovy code and turn it back into java.
I'm a software engineer who has until now mostly worked on web applications (backend and frontend). I have recently been learning Unity3D which has been immensely satisfying. The breadth and depth of skills needed to tackle projects in this field makes for some really interesting work. 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 projec…
Several obvious conclusions can be drawn:
1) I am an idiot
2) I am using the wrong training material
3) Unity3D is just not for me.
I am hoping it is #2, so I ask what path did you use to learn Unity3D?