It's pretty difficult to realize, but I have seen two ways to pull off remote work:
- Do work with a client locally for a while and earn their TRUST. Multiple contract renewals are a sign they really like you and need you and are likely to accept a remote working arrangement.
- Become a senior SWE and acquire enough skill and "brand" that you will be desired by the larger companies which make exceptions for this type of thing. I've many people, almost always in management roles, pull this quite well for a number of years. All the largest software companies have some remote managers and developers (Microsoft, Autodesk, even Google), even if at first contact they'll tell you they don't do that. Usually, those who get those exceptions are senior and their skill is in high demand (they're "experts" at something, or they're great managers).
I've never seen anybody get well-paid remote work in different circumstances (though that's not saying it's impossible).
When I first wrote Beancount (http://furius.ca/beancount) I wanted to reconstruct up to 7 years of history for some of my accounts. I ended up using PDF statements where I could get them, and entering some of the missing statements manually. If you have PDFs, cut-n-pasting into Emacs and massaging the entries to fit Ledger/Beancount's input syntax manually is possible (though a bit time-consuming). I created macros to help the task, it wasn't crazy.
If you use a double-entry accounting system like this, it'll save you so much hassle that you won't have to remember to reconcile: you'll just *want* to reconcile more often than you actually need to. It's really cool to know where the pennies are going.
I recommend "Learning Python" (M. Lutz) to my students, over any other book. This book both offers a great introduction to the language and explains the unifying concepts much clearer than any other Python book I've seen. It also goes deep into the details if you need it. The book oozes of the many years of experience of the author in teaching the language.
(That said, I haven't read the new book being reviewed in this article.)
It's always the same story: there is no silver bullet. Once your application will get "serious", you will have to occasionally dig down to the bare metal and debug at a lower level, optimize for performance, etc. And at that point you will need "real" knowledge. My advice: make sure you learn SQL, make sure you understand how the components work. If you're building the next amazon, forget about all that rapid app stuff (unless you're building a site for a friend which will get 2 visitors per day).
If you're a programmer, you spend most of your time in a shell or a text editor (i.e. emacs). Since you spend most of your time in the editor, soon you have LEARNED all its commands by heart, and the last thing that you want is a nice looking GUI to get in your way.
Goodbye menu-bar! Goodbye toolbar icons! Please get out of the way! All I need is a minibuffer and a keyboard. If the "glory days" you refer to mean I will get cluttered with all this good-looking nonsense, then you can trust I'll just grow into an old emacs user.
Emacs is bound to be misunderstood by those who have not made the effort to learn it; Yet it has such tremendous value accumulated in it that no other editor can ever come close to it. You only have to browse the lisp directory to discover this for yourself. To understand emacs, you have to make an effort, but the payoffs are not to be underestimated.
One thing that I always find so strange, is how people focus on the difficult learning aspect of the editor.
I understand that such usability is important for a web application users are going to access once/week or month or so, they have to be able to guess their way around, but for a programmer, your text editor is where you spend 10 hours/day. Who cares if it's a little hard to learn? Soon enough it'll be in your fingers anyway.
Learning emacs is the best practical investment I have ever done in my career, and it is the best computer program I have ever used! People who diss emacs invariably show lack of knowledge of it, and I have yet to meet a competent emacs user who was willing to change to something else.
For those who are tempted to think that Google is the first to come up a sleek interface for maps, check this interactive map of switzerland, it's very similar:
a great idea, i think this one will go far. when you recognize that most of the work people get in their lifes comes from personal contacts, extending your awareness of your personal network through linkedin can be a great help.
(btw i am not affiliated with these guys, just a happy member)
if you like simple, command-line utilities that work with ascii text files rather than the panoply of quicken/timeslips and other stuff like that (my home is Windows-free), i wrote a couple of little scripts that i use when i fulfill contracts, they've been working great for me:
http://furius.ca/contract-tools
(written in Python)
granted, i don't have a great number of contracts, and i still make my invoices "by hand" in gnumeric, but the timesheet script works really nicely, combined with docutils.
No surprise, cuba has been doing that for a while. Look up Cierra-Garcia hospital in Havana. You can often meet patients recovering to the sound of salsa music at the Casa de la Musica nearby.
it just strikes me as odd that everyone always rehashes the same old ideas about email and quibble over meaningless details. could we please stop thinking in terms of folders?
your email in a database, all folders are virtual folders, i.e. views on the whole email database, more details at: http://furius.ca/techdoc/projects/email-as-db .html
seriously, one way i've found to stop checking slashdot is to subscribe to the daily "stories" email. then i force myself NEVER to go to the website, and once a day, i quickly process all of the day's slashes in one go. i find this also makes me much more selective w.r.t. what i read from slashdot. soon i will make a filter program to only show the categories i'm interested in, with keywords and stuff (e.g. i'm not interested in anything to do with games).
another trick is the "buddy" system proposed by M. Desjardins in "How to Be a Good Graduate Student", but to apply it right you need someone who really cares about doing the weekly progress check meetings.
i had a similar experience with one of my oss projects. afaik it's the only decent tool that's out there for the job it does, i've had numerous companies send me thank you emails saying they've installed it for their whole r&d dept. for daily use, i even supported it for a few years in a commercial environment where i was working, >50 engineers using it daily. many distros now include it. it was written about in a few magazines.
yet it still doesn't come with redhat. RH didn't include anything similar either for the longest time, and even the tool that comes with rh9 now does not really address the feature set my project offers yet. i made sure the dependencies were small (qt only). i supported it under many other unices. i've been providing rpms myself for years. i even pointed it out to the RH guys themselves, got a message that it somehow went to germany. eventually it must have got lost somewhere, never heard of it anymore. i know some people at redhat use it themselves.
i really wonder what their selection process is.
i also wonder if their recent changes will make it more clear what their selection process is.
about (4) merging 3-way: you can use xxdiff (http://xxdiff.sourceforge.net) with any cm system by writing a thin wrapper that extracts the needed revisions and spawning xxdiff on the local files. you can select diff hunks and save the result to a "merged" file.
Slashdot Mirror
It's pretty difficult to realize, but I have seen two ways to pull off remote work:
- Do work with a client locally for a while and earn their TRUST. Multiple contract renewals are a sign they really like you and need you and are likely to accept a remote working arrangement.
- Become a senior SWE and acquire enough skill and "brand" that you will be desired by the larger companies which make exceptions for this type of thing. I've many people, almost always in management roles, pull this quite well for a number of years. All the largest software companies have some remote managers and developers (Microsoft, Autodesk, even Google), even if at first contact they'll tell you they don't do that. Usually, those who get those exceptions are senior and their skill is in high demand (they're "experts" at something, or they're great managers).
I've never seen anybody get well-paid remote work in different circumstances (though that's not saying it's impossible).
When I first wrote Beancount (http://furius.ca/beancount) I wanted to reconstruct up to 7 years of history for some of my accounts. I ended up using PDF statements where I could get them, and entering some of the missing statements manually. If you have PDFs, cut-n-pasting into Emacs and massaging the entries to fit Ledger/Beancount's input syntax manually is possible (though a bit time-consuming). I created macros to help the task, it wasn't crazy.
If you use a double-entry accounting system like this, it'll save you so much hassle that you won't have to remember to reconcile: you'll just *want* to reconcile more often than you actually need to. It's really cool to know where the pennies are going.
I offer a professional on-site Python training course (http://furius.ca/training/).
I recommend "Learning Python" (M. Lutz) to my students, over any other book. This book both offers a great introduction to the language and explains the unifying concepts much clearer than any other Python book I've seen. It also goes deep into the details if you need it. The book oozes of the many years of experience of the author in teaching the language.
(That said, I haven't read the new book being reviewed in this article.)
It's always the same story: there is no silver bullet. Once your application will get "serious", you will have to occasionally dig down to the bare metal and debug at a lower level, optimize for performance, etc. And at that point you will need "real" knowledge. My advice: make sure you learn SQL, make sure you understand how the components work. If you're building the next amazon, forget about all that rapid app stuff (unless you're building a site for a friend which will get 2 visitors per day).
This makes so little sense to me.
If you're a programmer, you spend most of your time in a shell or a text editor (i.e. emacs). Since you spend most of your time in the editor, soon you have LEARNED all its commands by heart, and the last thing that you want is a nice looking GUI to get in your way.
Goodbye menu-bar! Goodbye toolbar icons! Please get out of the way! All I need is a minibuffer and a keyboard. If the "glory days" you refer to mean I will get cluttered with all this good-looking nonsense, then you can trust I'll just grow into an old emacs user.
Emacs is bound to be misunderstood by those who have not made the effort to learn it; Yet it has such tremendous value accumulated in it that no other editor can ever come close to it. You only have to browse the lisp directory to discover this for yourself. To understand emacs, you have to make an effort, but the payoffs are not to be underestimated.
One thing that I always find so strange, is how people focus on the difficult learning aspect of the editor.
I understand that such usability is important for a web application users are going to access once/week or month or so, they have to be able to guess their way around, but for a programmer, your text editor is where you spend 10 hours/day. Who cares if it's a little hard to learn? Soon enough it'll be in your fingers anyway.
Learning emacs is the best practical investment I have ever done in my career, and it is the best computer program I have ever used! People who diss emacs invariably show lack of knowledge of it, and I have yet to meet a competent emacs user who was willing to change to something else.
Make the effort, it's definitely worth it.
oh well.
emerge --sync
emerge --changelog world
and i have a long list of new stuff every day.
For those who are tempted to think that Google is the first to come up a sleek interface for maps, check this interactive map of switzerland, it's very similar:
http://map.search.ch/
try: http://linkedin.com
a great idea, i think this one will go far. when you recognize that most of the work people get in their lifes comes from personal contacts, extending your awareness of your personal network through linkedin can be a great help.
(btw i am not affiliated with these guys, just a happy member)
if you like simple, command-line utilities that work with ascii text files rather than the panoply of quicken/timeslips and other stuff like that (my home is Windows-free), i wrote a couple of little scripts that i use when i fulfill contracts, they've been working great for me:
http://furius.ca/contract-tools
(written in Python)
granted, i don't have a great number of contracts, and i still make my invoices "by hand" in gnumeric, but the timesheet script works really nicely, combined with docutils.
cheers,
No surprise, cuba has been doing that for a while. Look up Cierra-Garcia hospital in Havana. You can often meet patients recovering to the sound of salsa music at the Casa de la Musica nearby.
it just strikes me as odd that everyone always rehashes the same old ideas about email and quibble over meaningless details. could we please stop thinking in terms of folders?
b .html
your email in a database, all folders are virtual folders, i.e. views on the whole email database, more details at:
http://furius.ca/techdoc/projects/email-as-d
seriously, one way i've found to stop checking slashdot is to subscribe to the daily "stories" email. then i force myself NEVER to go to the website, and once a day, i quickly process all of the day's slashes in one go. i find this also makes me much more selective w.r.t. what i read from slashdot. soon i will make a filter program to only show the categories i'm interested in, with keywords and stuff (e.g. i'm not interested in anything to do with games).
another trick is the "buddy" system proposed by M. Desjardins in "How to Be a Good Graduate Student", but to apply it right you need someone who really cares about doing the weekly progress check meetings.
http://www.cs.indiana.edu/how.2b/how.2b.html
i had a similar experience with one of my oss projects. afaik it's the only decent tool that's out there for the job it does, i've had numerous companies send me thank you emails saying they've installed it for their whole r&d dept. for daily use, i even supported it for a few years in a commercial environment where i was working, >50 engineers using it daily. many distros now include it. it was written about in a few magazines.
yet it still doesn't come with redhat. RH didn't include anything similar either for the longest time, and even the tool that comes with rh9 now does not really address the feature set my project offers yet. i made sure the dependencies were small (qt only). i supported it under many other unices. i've been providing rpms myself for years. i even pointed it out to the RH guys themselves, got a message that it somehow went to germany. eventually it must have got lost somewhere, never heard of it anymore. i know some people at redhat use it themselves.
i really wonder what their selection process is.
i also wonder if their recent changes will make it more clear what their selection process is.
about (4) merging 3-way: you can use xxdiff (http://xxdiff.sourceforge.net) with any cm system by writing a thin wrapper that extracts the needed revisions and spawning xxdiff on the local files. you can select diff hunks and save the result to a "merged" file.