If anything, the biggest problem I had was knowing that the client had an alloted pool of hours, and I had to make my solution fit within that budget. Many times, I gave them unbilled hours just to ship something I was happy with. That's a separate problem worthy of its own discussion at some other time.
But even if you do work extra hours in order to make more money, that's better than doing the same thing on salary. I see people now working 50+ hours a week, with no incentive other than, I suppose, a go-getter attitude that they hope will result in them working 50+ hours a week for more money, with a fancier title, someday.
My point is that the billing model by itself is neither the problem nor the solution: overworking yourself, or letting your employer overwork you, is something you can do under any system if you aren't careful.
For parents, one large gain is explaining your work to your kids. They get to see how you work, and this provides a template for them. Of course, whether this is good or not....
Then run RubyMine from Windows.
Make a work directory on Ubuntu that has the same branch checked out as your Windows work directory.
Then set up RubyMine: Tools -> Deployment -> Configuration... and set up remote rsync with automatic update of remote files from Windows.
Any file you change on Windows will automatically sync to Linux. You only need a script running on Linux to live update/restart your app on file changes.
I do a version of this for Ruby/Rails development with a cloud VM instance from Mac RubyMine editing machine.
The alternative gamer-mentality of tightly coupled cpu, gpu, and storage with huge IO is quite costly.
“I have a couple of sayings that are pertinent. The first is: ‘Successful people do what unsuccessful people won’t.’ The second is: ‘If you don’t put them [bugs] in, you don’t have to take them out.’ I am a person that wants to do the work. I don’t want to just think about it and let someone else do it. When presented with a programming problem, I formulate an appropriate solution and then proceed to write the code. While writing the code, I continually mentally execute the code in my head in an attempt to flush out any bugs. I am a great believer in incremental implementation, where a piece of the solution is done, verified to work properly, and then move on to the next piece. In my case, this leads to faster implementation with fewer bugs. Quality is my No. 1 constraint – always. I don’t want to produce any code that has bugs – none.
“So my advice is be a thinker doer,” Cutler concluded. “Focus on the problem to solve and give it your undivided attention and effort. Produce high-quality work that is secure.”
https://news.microsoft.com/features/the-engineers-engineer-c...
Unfortunately, I do not have this level of talent, but I do what I can.
These discussions seem like MBA brain-teasers, ie. there can't be any hard and fast rules, so each case needs to be individually worked out.
There's probably a sub-reddit for this.
find dev arch kern uvm -type d | while read dn; do printf "$(find $dn -type f | xargs wc -l | awk 'END {print $1}')\t$(du -h $dn | awk 'END {print $1}')\t${dn}\n"; done
Just kidding, but for smaller repos it gets the job done! And it's easy to run anything on each individual dir and add it to the output on the fly.
paths() {
dir=`dirname $1`
while test "$dir" != '/' && test "$dir" != '.' ; do
echo $dir
dir=`dirname $dir`
done
}
find $dir -type f -not -path '*/.git/*' | while read file; do
cnt=`wc -l < $file`
for d in `paths $file`; do
printf "%s\t%s\n" $cnt "$d"
done
done | awk '{
hierarchy[ $2 ] += $1;
}
END {
for (dir in hierarchy) {
printf("%8d %s\n", hierarchy[dir], dir)
}
}' | sort -rn | head | sort -k 2
Granted, the papers and progression were hand-picked by the prof. However, the final effect was that the students became fairly competent at reviewing papers in general.
I haven't, but could be interested; are there any good tutorials or such that you might suggest?
For an abstract, design/implementation introduction, though? There isn't. We don't learn about macro languages just as we don't learn about domain specific languages.
Before YAML or Dockerfiles, it was the way to declare state and reduce complexity for sysadmins. Basically, any time you had data that needed multiple projections (eg. hosts to forward and reverse zonefiles), you reached for m4. The same went for unwieldy configs (apache, sendmail, etc.).
Culturally, macro languages seem to be just learned ad-hoc, ie. how many here have had a class in m4 or TeX?
I would also mention topics like: - Reporting (various data aggregation and audit reports) - High reliability, nothing hurts company more than unability to bill their customers - Rounding, this can be seen as a subset of "taxes" but it's much more complex - Locating user, also can be seen as a subset of "taxes" but user can have country A set in profile configurations, country B on credit card and country C geolocated from IP address - Timezones, issue everywhere but when we talk accounting it's super important - Talking to moronic payment gateway providers. This is the biggest ones. I would love to just flip Apple and Google like Linus flipped of nVidia. Proprietary, poorly documented, "find out yourself by weeks of experimenting" bullshit with no easy way of getting technical support even when you bring those companies millions per year. Things don't work, deprecate monthly or weekly and expect you to be always ready to make changes. Some implementation make zero sense at all with complete paradigm shift of handling payments like between Google in-app pay and Google subscriptions.
But as my SO says "Don't cry, it pays well"
And it's not "billing", it's Compliance + Bill Presentment (marketing!) where we are always trying to find the most profitable local maximum of explainability to Sales, Customers, and Management/Enforcement while also having hard checks to prevent or at least mitigate losses.
No one wants a Knight Trading excursion....
How many BOFHs generated keys for everyone, mailed them out, and disabled telnetd / rlogind?