I'd read managing humans, and other people skills books. You will most likely want to learn how to rely on your peers to build better software than you. Your job as a leader will be more important in your ability to make sure your team is doing the right thing rather than how they do it.
It's when you start to think you know everything that people don't like to work with you. I haven't met that many people in my software career ~15yrs that have enjoyed working with a know-it-all.
You can of course be super smart at your job and know a TON, but when you start acting cocky and like you know everything it usually doesn't end well.
I followed option A in my career. I quit, went back to school to finish my degree and worked part time as a contractor for enough money to maintain my mortgage while in school.
Anyway, it is very important to learn to work closely with a team. It is also VERY important that you work with people that are SMARTER than you. IMHO, this is the best way to get proper mentor-ship and motivation to learn. I personally try to surround myself with people that are smarter than me.
Once you think that you know "everything" or that you're the smartest person in the room, it's time to change jobs. Because:
A) People won't like working with you
B) You'll stop learning new things since you already know everything.
This looks great! I'll be downloading the trial for sure. I wonder if it'll work with gdbserver for remote target debugging? UndoDB's site says it works for Android, but they mention that it's native Android not remote. Anyone have any experience with that?
This is pretty awesome! In the past I worked on a project which we implemented a control-plane/data-plane separation architecture within Linux. The system had two CPUs and we had Linux running on one with configuration apps and all network related IO ran on the other CPU.
The problem was that this was implemented at the kernel level and whenever an application needed to share data across the CPUs it was slow. The implementation could have probably been better, but this was a long time ago and I can't recall everything that was done.
Regardless, Arrakis looks like a great project with a lot of potential.
Imagine this type of stack being used in an embedded system. I've worked on embedded projects that achieved high throughput but in most cases there were FPGAs and DSPs doing a lot work to help. Userspace-to-Kernel context switch delays have always been a latency issue with any Embedded Linux system I've worked on.
Arrakis looks like one would be able to achieve high performance without the need for FPGA and or DSP (depending on the use case of course).
Side note:
Cool, I noticed they're using lwip from Adam Dunkels. He's an amazing programmer.
$8.50/hr may be a lot for where OP lives based on their experience. I would think that OP is not living in the US. Hopefully OP can provide some insight here.
Not to hijack this thread, but I'd like to hear more about remote rates of other platform developers as well (php,nodejs,python,.net, etc). A nice comparison matrix would be awesome. Anyone know of a site that specifically compares these rates across the globe?
I could see a matrix like this being a great addon to remote job sites. Those of you who have created a work-remote job site and are competing to weworkremotely, etc... I would think that this would bring you a lot more traffic.
Not for that specific project no. In the past ~2002 timeframe we used WxWidgets back when it was still WxWindows for a Linux desktop frontend. But other than that, I haven't played around with it lately.
OK, I get it. The hashing would become slow on each file (especially large ones). And given that git is designed to give you the whole repo history, yes, cloning would be slow with repos with a lot of history.
It seems like 2 of the main reasons Perforce works better with binary files is that when you sync, you only get the version you're requesting, thus resulting in faster downloads and there's an option to disable compression.
"Just about any big game studio uses P4 these days. I haven't seen one that doesn't."
That's a very interesting statement. I wonder why? Maybe it's just grandfathered into these companies. IMHO, even if you're an enterprise software shop I think git can handle that with the proper tools and practices.
I'm currently having to use Accurev in an enterprise environment, but I haven't run into anything that Accurev offers that can't be accomplished with git in a better and faster way. But then again, that's just my opinion :-)
Although I use git these days and wouldn't go back to P4 if you paid me. I still sometimes use p4merge for my difftool and I always thought they did a great job with their client UI with Qt. So, yay for p4 and Qt.
In the past, I wrote a server app that was supposed to be cross-platform (Windows, Linux, Embedded Linux and eventually OSX). I chose to write it in C++ & Qt. That ended up being a bad decision because of the bloat. Since we needed the app to be able to run on embedded systems we couldn't use Qt. (We eventually wanted to be able to run on VxWorks as well). So, the size of the binary was too large. Eventually, I rewrote the app in ANSI C and saved a huge amount in the size of the static binary IIRC ~4MB (Warning, I don't remember exactly). The #ifdef code for each platform was one .c file for each OS with just a few functions on how to start/stop the service etc...
The problem you have there is not only one of outdated hardware, but also an issue of software certification and other software red-tape in that industry. A friend of mine was working on one of those systems in the past (IIRC, they used Qt) and it takes a long time for that stuff to get released...
This++
I've used Qt for desktop apps as well as apps on Embedded Linux. I've even used it with a Lua wrapper API that made development even easier.
Is it a bit bloated? Yes. But unless you are very constrained for memory and flash space it should fit in your embedded system. They also have a way for you to select which components you want to compile for your target, allowing you to control how much of the bloat you actually use. :)
Am I the only one that looks at some of these graphs and thinks OMG THE BLOAT! and runs in the opposite direction? These days with a lot of app dev the deps go deep and a tool like this draws a very informative picture.