Say I find a Windows developer with 10+ years of experience, great skills in C/C++ and excellent references as a versatile coder who gets things done. Can I hire him for development on the Linux platform and expect him to be efficient in production within a couple of weeks? Or is the threshold too high when speaking in terms of development environment and all the common tools used in daily work? What are the main obstacles for this person to overcome?
Note, this is a general question, where I basically assume typical Windows and Linux environments (Visual Studio vs. Eclipse or EMACS, Add/Remove programs vs. apt-get, dialog wizards vs. commandline, and so on)
It really depends on a lot of factors.
A really good developer will be able to learn everything they need to know fairly quickly. The main language is the same.
However, depending on what you're developing on Linux, there may be some major learning curves to overcome.
A couple of examples:
The entire operating system APIs are different.
If you're using any large libraries, there will be a learning curve to the library.
If you're using more traditional unix build systems, there will (possibly) be a learning curve to using those vs. the normal "Windows way" of working in an IDE like Visual Studio.
I think expecting to have a perfect dev. in 2 weeks is probably a bit ambitious - but if they're good, they'll get productive quickly.
I was exactly such a developer not long ago (but I did have some *nix experience way back).
For me personally, I found the initial transition very easy. There are adequate tools for everything you need to do to at least get coding. The second phase was very difficult - finding exactly the right tools for what I was doing, and how to use those tools. I was dropped into this particular project alone, so I had no one but Google to ask, and it did take a long time to learn the keyboard shortcuts and whatnot of the new IDEs and compiler switches.
I felt, at the time, that if I had had someone to ask questions of, the whole thing would have taken a lot less time.
So long answer short: I think any good programmer won't have trouble with the easy stuff, but make sure the new dev is told frequently and in a friendly manner that everyone else is there to help answer questions.
I've attempted to switch to Linux/Unix many times. I can basically find my way around the box and do development [if I've got Mono]. Now, I can be equally as efficient in terms of basic user requirements on just about any box in a short amount of time, but if you expect me to be able to figure out all the installation, configuration and all the other stuff that comes with system maintenance in that short a period of time, I daresay I'd pull all my hair out before the two weeks was up. Invariably, someone will ask me to do something I have no idea to do in Linux/Unix and will end up switcing back to Windows because I can easily do it in a short time.
I'd say if they have other people to ask questions, sure, it's a piece of cake. If you expect them to kind of hit the ground running as a self starter, it's doubtful.
Great developers will be great on any platform. It may take him a little while, but if he is the "gets things done" sort, he should be able to get up to speed and make positive contributions to the project.
I think yes, but you might need to be patient for a longer ramp-up time. An idea: give him a Windows box with a Linux virtual machine running inside (or vice-versa), so if he runs into something he can't do quickly in Linux, he can switch over to Windows for that particular task until he becomes more proficient on the Linux side. This may mitigate some of the "separation anxiety" some windows users have when switching to Linux. Think of it as "Linux with training wheels."
Good programmers is good programmers, and they're hard to find. You can make it work if you want to.
Well if he really is a guru, I would say yes. Many studies show that a good programmer produces more that 10 times as much useful work in a day as an average programmer. A real guru probably produces 100 times as much.
So given a choice between a WIndows guru and an average Linux guy, I'd ttake the guru any day.
Why can't you hire a Linux guru instead?
That's funny how many people have come to declare "Yes sure he can".
Why nobody asks whether he would want to?
There is no doubt that Windows guru (if that is true) can handle the Linux stuff.
The only thing you should ask yourself is how much time do you have 4 the project, as you can't expect somebody that was never developing in Linux to be as fast as someone else who does that for some time.
If you can afford to let the man have some time to take a running stance, you should give him a go.
I think it depends. If you take away a man's Visual Studio, you are halving his productivity right there. If you are doing everything in emacs with commandline compilers, you've probably just lopped off another half of his productivity. Now, some of this will creep up over time as he becomes more familiar, but you can pretty much bet that this guru will never be as productive on Linux without the IDE.
If I can remember back into the Bronze Age, when I learned programming on Unix, the technique I used was to learn things as close to one at a time as I could. I didn't learn vi until I was already reasonably comfortable with C. Then I learned make, and then studied the Unix API. Eventually, it got to the point where I was just learning what I needed to know when I needed to know it, but it took months.
At least the guy you're talking about is proficient in C and C++. Get him a halfway decent IDE if he doesn't want to tackle vi or Emacs and make. The big question then is the APIs in use; they may take some time to internalize. And make sure you've got somebody to answer the simple little questions and do some of the smaller but potentially confusing things for a while.
Related
No I didn't reverse my operating systems in that question! My background has been exclusively Linux/OSX to date, and I honestly don't know a thing about Windows development. Visusal *, *.NET, Powershell, WinForms, Win32, not a clue. They're just words to me. This is starting to be a problem because I've been tasked to port Linux/OSX software to Windows, and Cygwin doesn't begin to cut it.
Does anyone have advice on how to get into Windows development tools? There are a million introductions to UNIX out there, but every google search for "Windows for Linux programmers" gets the opposite result!
EDIT: To give more information I guess what I need the most right now is to learn how to compile and cross-compile using the Microsoft compilers, an overview of the Windows libraries (I guess that's the .NET stuff?), and Powershell. Sorry for being so broad. I guess what's happening is when I sit in front of a Windows machine I revert to a web surfer instead of a programmer because I don't know any of the standard tools outside of Cygwin.
This is going to sound snippy, and I don't mean it that way, but...
Is it at all possible to involve a Windows developer in this effort? It takes a significant amount of time to come up to speed in windows, and if you've been tasked with porting code over, you probably haven't been allocated enough time to come up to speed before starting work. Even bringing in a consultant would provide you with someone to get you going, and steer you away from the rocks once in a while.
I did a numeric method as my diploma thesis and coded it in java. It needs a lot of computational time when adequately executed. So I looked for an alternative and found BOINC. Unfortunately I didn't have time for doing my method in BOINC, because I'm an Aerospace student and not a programmer and I decided to keep my priority on my java program. Now it's finished an I still would like to port this to BOINC environment.
Unfortunately I'm learning in re-doing examples and I couldn't find any, neither on the official site http://boinc.berkeley.edu nor in the internet.
So do you know a good and easy example or do you have any experience in BOINC and would like to start a new platform for such a boinc project?
I'm realistic about my method, that it wouldn't run 24/7, because there aren't as many work units as for seti or folding projects. So I would like to have a platform for more than just my project so that another platform project can be worked on, when one part of the project does not have any work units at that moment.
But to start this, I would keep it simple and just want to know how to code it and use it in the client and server system. It doesn't matter what the example projects will work on, as long as it is simple enough, that I can understand it and extending it for my method.
Thank you in advance, Andreas! :)
PS: I know that BOINC supports JAVA as a programming language, and my method is coded in JAVA.
As far as I know, JavaApps is just an idea; I don't know if anyone actually tried it in a real BOINC project. And it's Windows-only. And it seems to be a bit of a pain to redistribute the entire JRE as part of the BOINC application (both technically and legally).
Also, I generally dislike using that kind of “wrapper” where the science app (using the BOINC API) starts another process that then does the real computation. It's usually unreliable. There are lots of things that could go wrong with the wrapper, especially related to controlling the child process (eg. if something kills the wrapper, the child process has to quit too).
However, I just found something pretty interesting that may let me do a better Java wrapper for BOINC... Stay tuned! (but don't hold your breath either; it's the holidays!)
Meanwhile, I suggest you start by reading BOINC wiki and setting up a server with a “hello world” application; and if you have any trouble, ask a specific question about your trouble either here or in the boinc_projects mailing list.
(Of course, payin’ me to install the server for you is also an option ;) but I can't guarantee anything; not even my mere availability at this time of the year)
Is there any way to make an installer that is very user friendly?
I know it's impossible for a Next Next Finished installer but what can I do to ease the process?
Windows platform.
Thanks in advance.
If you've got a very simple application and basically just need to copy a few files, I'd suggest looking at NSIS. It's very simple and you can probably have an installer done in a couple of days.
If you're developing software for a corporate environment where network rollouts are a priority, then you'll probably want to take a closer look at Windows Installer and Windows Installer XML (WiX). (Warning: a very steep learning curve - you'll want to set aside a few weeks and probably read this book to help get started)
If you want the benefits of MSI, without the hassle of learning the underlying technology then a commercial tool such as Installshield is your best bet. It's not cheap but you'll get something out the door pretty quickly.
Long term I'd advise learning Windows Installer technology. It's something overlooked by most developers, it's often seen as crazy voodoo that is overly complicated and unnecessary, in reality it's rather quite simple, just a database with a whole bunch of rules, conditions, and quirks that take a bit of getting used to :)
Try BitNami WAMPStack it is open source and free (you also have Linux and OS X versions)
If I understand your question correctly, I'm not sure how you didn't find this already...
http://www.wampserver.com/en/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm looking for some help and it goes like this:
I'm a fairly green software developer, and focus mainly on the web (python/PHP) but am pretty well experienced with Java applications and as an electrical engineering student, looking forward to dive into some c/c++. I've pretty much grown up on Windows machine, but hate .net with a passion and dont really have a need to develop on Windows - besides the fact that i'm used to it.
I'm looking to switch to Ubuntu as my development machine entirely (without having WinXP on another partition) as I'm quite fedup with Windows, but am tempted to go back to it everytime i'm stuck with countless driver issues (be it headphone drivers, or dual monitor setup, etc). I'm looking for a comprehensive resource that will help this transition and doesn't assume you know alien linux shell keywords.
Cheers.
In my personal experience with Ubuntu, the two places that I consistently found help were Ubuntu Forums and Ubuntu Wiki. These two sites demonstrate just how helpful, organized, and motivated the Ubuntu Community is.
An additional resource is also the Ubuntu channel on IRC. Whenever I was stuck with an issue that I felt warranted a discussion with someone (or a handful of people), IRC was always a good place to go.
Lastly, I tend to learn a lot from reading blogs from people that are heavily involved in Ubuntu's development. Planet Ubuntu is a pretty good feed to keep in your reader. It's essentially an aggregation of a number of blogs. The majority of the posts are related to Ubuntu; however, there are occasional posts that are just about the developer's thoughts and opinions.
I would recommend you set up your PC in such a way that:
Have three partitions, one for swap (1-2x ram size), one for / (root dir) and one for /home.
Keep everything not related to running linux in /home, or on completely separate harddrives. Don't store stuff you wanna keep on the partition that holds /.
This allows you to rather effectively nuke your entire linux install and install another one without losing your data or your settings. This lets you do two things:
If you really break your install you can often just nuke it and reinstall. Most distros you're going to try will deal with upgrading you back to the current version quickly.
If you're not happy with, say, Ubuntu, you can just nuke it and install something else, say OpenSUSE, CentOS or Fedora.
The key thing to remember is that all your personal settings (desktop background, application settings etc) are stored in /home/yourname/ under hidden directories, definied by naming them with a '.', .gnome for example. System settings are stored in /etc, but with most distros these days system settings are so well guessed you never need to care. The data you care is under /home/yourname.
If you're going to move to another distro I would recommend copying those hidden directories into another directory under your home/yourname directory, say 'old-prefs' or something. This is because you want to start 'fresh' with the new install. You can copy back hidden dirs you know you want later (I for example would always copy back .opera, .mozilla).
Also, don't throw away your Windows install, not yet anyway. You may find Linux is not for you. You may find the inability to play any new games without rebooting a pain. You may find various things don't work as seemlessly as they do on Windows, in my experience that includes Adobe Flash and various sound-related things (sound has recently been rooted imo due to early PulseAudio adoption).
As other people have said, the Ubuntu wiki and Ubuntu forums are good, and for that reason it's the first distro I suggest you try. It's so popular that you often get better results in google by replacing 'linux' with 'ubuntu'.
Not an answer, per se, but some unsolicited advice:
All platforms have problems
Developing on one platform is pretty much like developing on another
Familiarity with both the *nix and Windows worlds is useful
Good luck!
I would agree with Tom's answer in terms of resources to answer questions. In addition to that, I would recommend being prepared to learn to use a command prompt and to learn a lot more about the underpinnings of the system than you are probably used to on Windows. Linux in general exposes the "machinery" of the OS quite a bit more frequently than Windows, and if you're the type of person that doesn't like to tinker with things occasionally then it is probably not for you.
For example, my dad is an engineer and experienced programmer, and he has no interest in using Linux, because he doesn't want to have to futz with things to get them working. For him, using Windows is all about the path of least resistance. I on the other hand, use OS X and Linux on a regular basis and I love that when things don't work, I at least have the option of digging in and fixing the problem. I love the ready availability of command line interfaces, multitude of scripting options, and the general openness Linux has. It's hard to tell from your post which type of personality you have, but if you're looking forward to digging into C/C++ and you enjoy electrical engineering, Linux will probably be a good fit for you.
Lastly, I highly recommend using the command prompt frequently, even when there are GUI interfaces. Linux GUI apps are frequently built on top of the console applications. It almost always will be easier to work with things if you're familiar with and comfortable with the command line. Most seasoned *nix users also find that eventually it becomes more efficient and comfortable to get many types of tasks done from a command prompt. If you plan to develop on Linux then this is all the more likely to occur as you get used to thinks like working with build tools and scripts that are common on UNIX platforms.
EDIT: One last thing I cannot recommend enough: use virtualization! Install something like VirtualBox, VirtualPC or VMWare Player to run Linux in a virtual environment. Virtualization has come along far enough since the days I started using Linux such that you can now install and run Linux in a full-screen environment almost indistinguishable from running it natively. Using a virtualized environemtn also will make things like drivers a non-issue, since the generic "hardware" should be supported out of the box. Virtualization or a "Live CD" version of Linux (such as the Ubuntu live CD) is a fantastic way to get used to Linux without having to throw out the safety blanket of Windows right away.
The other advice here is excellent. As somebody who made the same leap at the end of 2005, I just wanted to add my own two penneth.
Expect a steep learning curve. I'd been using Unix / Linux type servers for best part of 13 years when I switched. Not the same. When I switched is when I started learning. My productivity dipped at first, but I know SO much more about our deployment environment now - and of course productivity back an exceeded original. But it 'aint easy.
When you DO switch, you never look at an OS in the same way again. Makes it easy treating any OS as just a set of things you have to learn. This in itself is a good thing (tm)
The biggest problem at first is looking for linux equivalents of windows ways of doing things. I remember looking for decent FTP client (in the end IF I am forced to use FTP now, I use konqueror with two windows - but just wait till you discover rsync!), a decent graphical subversion client (then realised that knowing how to use find, sed, grep and svn cmd line client was much much better) etc.
I have heard people before say that resorting to the command line is admission of failure. While this may be true if there is no choice in it, you soon come to revel the blending of graphical and command line tools to get the job done. For example, I tend to use find and grep and xargs to load up my IDE with stuff I want to work on.
You learn to love computing again. The whole computer becomes a tool for getting things done.
The biggest change is the freedom. Not the cost. But that fact that installing software is as simple as "sudo apt-get install" or graphical equivalent. Even a very non-technical windows user soon comes to relish this amazing aspect that of Linux.
Enjoy!
What conversion/rewrite have you been involved with that failed? What where the languages and framework involved in the process? How large was the software in question? Finally what is the top one or two thing you learned from being involved with the process.
This is related to this question.
One of my favorites was a fixed price project developing a server app on Sun OS 3 that was eventually required to run on an old Data General machine running some (at the time) current version of Unix.
Now, we knew ahead of time it would be painful porting the C code to the Data General because it had 9 bit bytes / 36 bit words but didn't realize how ... lacking... the Unix implementation would be.
It was approximately 5 hours from the start of the porting task when the wise executive decision was made to simply buy the customer a shiny new Sun box.
I had one recently that largely failed due to my inability to thoroughly convince management that rewriting the app would be cheaper in the long run than to keep maintaining it as it was. If I had only read up on technical debt sooner, it may have been a success. Jeff's latest article on the topic was about 8 months too late for me!
All told the app was about 75K lines of C# code but it was a maintenance nightmare (in-house application). A handful of god classes and the rest were what I called puppet classes (classes by name only, the god classes "pulled the strings" for everything they did). Almost nothing was user-configurable so developers were responsible for everything.
In hindsight, the biggest roadblock to success was the app itself. Keeping it running was a full-time job for 3 of us. I think the best thing we could have done was to keep on refactoring. The "version 2" app had some real good concepts and we should have kept on trying to get them integrated instead of starting over... Had we done that, we could have built the big components after stabilizing the original app.
I once attempted to port a game I wrote in DarkBasic to C.
The problem I ran into was that DarkBasic was such a limited language (for example, no argument passing by reference) when I ported it I attempted to do a straight port... IE, I tried not to refactor it appropriately for the language I was using...
The result was a big mess...
I probably could have gotten it working, but I stopped after about 2 days because I realized it needed more than just translation to move to C...
I had written a Pacman clone using C and Allegro back in the day and I tried to rewrite it to run on the Dreamcast.
That was some horrible code. I couldn't really salvage much from the code base and scrapped the idea.
I learned that regardless of what I thought at the time, I was a really horrible programmer back then and I had learned a lot in the passing years. It also made me realize that in a few years time, I should learn enough to look back on the code I was writing today and think the same thing. Basically, I should always strive to become better.
I was once asked to convert a program which drove a photo typsetter on a DEC-System10 to IBM 4381. Looking at the code, I discovered that the original developer had, for no obvious reason, written various bits of the program in the following different languages:
DEC FORTRAN
Algol 68
BCPL
MACRO-10
This was a great testimony to DEC's support for multi-language programming, but it was the only time I've had to go to a user and say "No can do".