Related
I've been trying to figure out what computer field I want to go into later on in life. College is just around the corner for me and I've considered looking into Computer Engineering, Software Engineering, etc.
Lately, I've been looking into computer security systems and exploitations of such (purely for educational purposes, on my own property). Unfortunately, it seems to me like 99% of the people out there have no idea what they're talking about. Oftentimes, it's just "run this" or "run that" or "you can find a program that will do all that for you" - no one knows how these programs work or what exactly they do.
I find no fun or interest in using something that someone else created simply to call myself a "hacker" as most people do. In fact, I'm not even interested in hacking systems as much as HOW they do it.
My question all comes down to this.
I want to learn the ins, outs, ups, and downs of computers - everything from abstract concepts such as the internet and data transferral, to hardware. I want to know how computers store data (how the bites are organized, etc.) and what processors, etc. actually do. What is WIFI, really? Do computers communicate with light (something I picked up from a magazine that I read on a plane).
I have multiple years of computer/programming experience, but so much of what I know about computers in general is very broad. Computers send packages of information back and forth between one another, each with a header and content. Computers are composed of multiple components, each with their own function (processor, video card, RAM, hard drive(s), etc.), which I have some basic understanding of already. etc. etc. etc.
There is just so much to a computer and I don't know where to start. I'm sure some of my college classes will clear things up for me, but I'm so curious that I want to start learning as much as I can now.
This question is probably all over the place, so please ask me to clarify when necessary. I'm a little jet lagged at the moment, but I tried to write my thoughts in the quickest, most coherent way possible (I could have completely failed in the process, though).
Thanks in advance for any advice!
Justian Meyer
Please, feel free to edit the tags for this question. The current ones are terrible.
EDIT:
All these comments are making me excited :). So much to learn, so much to explore :).
To help you choose which specialization to go into, I would very highly recommend computer engineering(Known as CMPE or CE in college course books). Your classes will take you to everything you just listed, and with electives you can delve deeper into whichever aspects you wish(such as security and networking).
In CMPE you will learn both software(C, C++, and some C#) and then hardware( maybe two electrical engineering classes). Once you get to assembly programming, you will start to learn how the two combine to make up everything else in any computer or embedded system. It will take you down to the bit level of memory, CPU, data buses, I/O, and so many other things. I am just starting to do Digital Design, and its ****ing glorious. From what you described, you will enjoy being a CMPE major greatly.
There's computer science majors and software engineers; there's electrical engineers; but there is no cell phone, GPS, or computer designed without computer engineers!
Structured Computer Organization, Tanenbaum
It is a great book and explains everything from a transistor to a Java virtual machine.
These two helped me understand how the OS and memory in general works.
I believe a lot of things are derived out of these 'simple mechanics.
1.Anatomy of a program in memory
2.Pushing the limits on Windows memory
Steve Gibson of security now has been doing a series of podcasts on computer basics.
http://www.grc.com/securitynow.htm Episode 233 "Let's Design a Computer (part 1)" up to the most recent one "What We'll Do for Speed".
Every other episode he does listener feedback and those are good to listen to too.
a few times (like right now) they interrupted the series if a important security news item comes up (like when that big SSL thing broke a few months ago)
Its a really good show and I recommend starting on 233 and working your way up, then starting over on episode 1. Has also done very good series on how a computer network works and how cryptography works. (Ep 203 will blow your mind when he talks about the Boyer & Moore
method of searching)
Since you are deciding where to go exactly, to be in software development or to become expert in hardware and networking, I would like to point out that in my opinion it is two different occupations and they require two different mindsets. Good hardware experts are usually not good programmers and good programmers almost always not experts in hardware and networking. So I would say don't try to embrace both, stick to one direction which is most suitable to your mindset. To pursue two rabbits would result in catching no one.
#Justian
I see, sorry I somewhat misunderstood you. Desire to understand intricacies of how code gets processed inside of hardware is a very natural one. When in college I was reading the book "How computer works" - it is fairly simple, even somewhat primitive book about general hardware functionality. But it can get you a broad look on the topic.
Another analogy came to mind. Say linguists research internal mechanics of language, but it is neuroscientists who research on how language signals get processed in brain. Two very different occupations. This is not to discourage you from learning hardware though, this is just to underline difference between two realms.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
As a developer who's never worked in Agile specifically (but have worked in TDD shops), I see employers that are running Agile shops resistant to hiring someone who hasn't worked in Agile. I've run into this a few times over the past few years. Is it really that fundamental of a philosophy change? After working in TDD, I can almost make an argument for not hiring someone who's never done TDD (when working in a heavy TDD environment). Perhaps I don't understand Agile and the difference between it and TDD.
I'd actually like to work in Agile, but this seems to be one of those times where you have to have the experience to get the experience. Sure, you can do it on your own, but that doesn't qualify if you ask me. As an employer, I wouldn't really call it applicable.
Agile is not an engineering philosophy in the strict sense - TDD, Peer Programming, etc are engineering practices that Agile uses - but rather Agile is a management methodology. As such, it's more important that someone be open to the mindset that Agile demands, rather than them actually having worked in an Agile shop before. Yes, it really is a different philosophy and approach to software development. People who expect everything up front and to be told what they need to do will be very out of place in an agile environment.
When I have interviewed people, I do ask whether they have any Agile experience or knowledge, but what I really look for are some of the following:
Flexible mindset
Confidence to allow self-empowerment (critical in any agile environment)
Ability to self-assign tasks
Communication skills (top 3 most important)
Ok with vague instructions, able to self-teach
Those are some of the qualities that I think qualify someone to work in an Agile environment.
Having an understanding of what Agile's core principles are is important to understanding Agile. TDD is just a small part of Agile and more specifically XP (Extreme Programming).
First I would take a look at the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Then I would take a look at the SCRUM process (which is also a small part of Agile) to see what's involved there.
When I interview developers I look to see that they have an understanding of Agile and what that entails so that I can then determine if the Agile enviroment/mentality is one what they would enjoy working in.
I've hired developers into agile teams quite a few times. I'm not at all resistant to hiring a developer with no prior agile experience - they'll be slightly cheaper ;-)
However there are questions that I would ask such a candidate and there are certain responses that set off alarm bells - letting me know that this person is going to be too much work to re-train.
For instance being precious about their code and designs - a sure sign they'll be a 'mare in scrums and code reviews.
Agile is an extreme democracy - everyone is equal, but that doesn't suit everyone. Some developers just seem happier in an autocracy (tell me what to do and how to do it), monarchy (layers of middle management) or bureaucracy (specs and development by rote) - those guys just don't work in agile.
Some developers are much happier with the agile ideas, and those guys can get hired whether they have have prior agile or not.
I wouldn't worry about not knowing all the process details - good developers read up and stay current on the technologies they use, not process methodology. Since every company tailors their agile model anyway (if they don't they're doing it wrong) it really doesn't matter which variant they started with. You should know some of the terminology, but that takes a day of reading up before the interview at most.
The brand of agile that we use is composed of Project Management Practices as defined by SCRUM and Engineering Practices as defined by XP. If we are starting a new team, we will look for key roles to serve as embedded coaches for the team (an Iteration Manager/ Scrum Master Coach, Analyst Coach, Technical Coach and Testing Coach). For an existing team, given that we use pairing, we are more interested in developers that work well with others than a super programmer.
Because we using pairing, a new developer will become productive within a month with the agile engineering practices as well as the business and application domains. It provides the team with little value if a strong programmer joins the team but is unable to pair effectively.
When we interview, we ask the candidates to pair with several team members. Through pairing, we learn if the developer works well with others in a pair. In addition, we gain insight into the developer's technical skills. Because the candidate works in several pairs, we get the perspective of a number of team members.
All of our agile teams have been very effective and their projects successful. We have trained more team members to become effective with agile than we have hired experienced agile personnel.
I think it is a typical case of over-insisting on a specific skill set. Like employers who don't want someone who knows JBoss when they use BEA for their application server.
A good employer will recognize if someone is adaptable to an agile method or not. Now if they have two otherwise equal candidates in front of them, perhaps that is a bit different.
It is certainly a handy way out of having to explain other reasons that may play a more important role in the decision.
Any company or opportunity that dictates SDLC by practice instead of best fit for the current project/situation is already showing signs of it's limitations and you are probably better served continuing your job search.
Absolutely YES
There's a lot of teamwork and trusting your peers in agile and specifically in extreme programming. You need to know other people are writing decent tests and not breaking your code. Good XP developers don't want people on the team that are going to make their job much harder.
Nothing wrong with being a beginner, or somebody new to a team - but there is an element of building trust just like you would to get committer rights in open source.
These days everybody says they are agile and if you offer enough money, practically everybody with the slightest tech skill will apply for the job... so expect people to put you through a pair-programming interview.
Typically we need to know:
Can you really pair program?
Do you really know how to do TDD?
Are you just saying these things or can you demonstrate you do them?
Are you going to take the initiative or are you waiting for an old-school "project manager"-type to tell you what to do?
Stuff that will help get you hired in an agile shop:
You have tried to introduce test-driven development somewhere even if you didn't get buy-in. (It worked for me...)
You have sample code you wrote - or an open source project on which you can demonstrate test-driven development, automated builds...
You find that you've worked in teams with short release cycles ...
In your current job, can you implement some form of Agile Developement to show you are interested, have looked into it and actually have some experience? You may be able to find some non-developers to work with you. A power-user could sit with you during some coding. I'm sure no one would get in the way of using some of the Agile documentation (sprint log, burn chart).
I'd likely put forth this question: What development methodologies have you been using up to this point in your career? Do any of them encompass the spirit of Agile's ideals?
If you are someone that loves to develop via Waterfall and think it is just absolutely perfect for your world of development, then going Agile would be like going from driving a car to flying a plane or a boat. It is that fundamental a difference as you aren't going to necessarily know where you are going and deal with changes very differently than a waterfall style where each stage goes in order and there isn't any reprioritizing without jeopardizing the whole process.
When a company uses the umbrella term "Agile" in recruiting without being more specific (e.g, by asking for XP or Scrum experience), it's often a placeholder for something else they're looking for. They may want "developers who will pair program" or "developers who won't dig in their heels about not having requirement and design documents before they get started" or "developers who won't go off into a dark corner for weeks on end". The trick is to figure out what they mean.
From a narrow Silicon Valley hiring perspective, a candidate who is familiar with Agile practices (e.g., knows what XP is), has done some of them (e.g., pair programming and TDD), and who wants to work in an Agile environment gets past that hurdle.
Employers most likely stick to hiring people who are knowledgeable of agile, rather than not, because agile methodologies require that almost every team member know about the processes required by each agile methodology (SCRUM, Crystal, XP). For example, SCRUM requires that all team members, including management, understand and follow the concept of self-organization. They’ll need to understand that they won’t be dictated on their current performance: They need to instead address their issues openly (or what typically happens at the daily SCRUM). If you put someone on the team who does not know agile, they may immediately assume that since this methodology has low documentation, they can run in and code-and-fix to build a project. However, agile methodologies are process-heavy, rather than documentation-heavy.
I understand your frustration but the truth is, if you never worked in an Agile environment you are very likely to behave in counter-agile ways (so to speak), and you will likely not even understand what is it that you are doing wrong.
Since Agile is so much about work philosophy it's not something you can learn merely by reading a book, you need to have intimate understanding of how non-Agile firms operate, what issues this causes, how Agile changes that, and how you to fight the entropy (the attempts of the external world to introduce the non-agility back in).
My advice is that you first read more about Agile and start analyzing your own behavior and behavior of whatever firm you currently working at from the Agility/non-Agility perspective. Once you're able to discern the patterns, you can start trying to change your firm from within. When you fail with that, go to an Agile company and they will hire you, I promise.
Maybe they take the mentality of the barkeep in the Mos Eisley cantina (paraphrased):
We don't want your kind here.
Community Wiki Question
Every time I work on a project involving passwords or securing data I get mired down into obscenely complex APIs and issues. I have not had much formal training in developing secure applications but I have not had much formal training in database, GUI, and build processes either. Many other areas of programming feel more intuitive.
Is security just a far more complex area than many others? I tend to think that it is not. Are security infterfaces and systems less mature than others? I would tend to think that there is a great deal of pressure for those systems to mature. On UNIX the 'trusted environment' was the norm until somewhere in the 90s. Is UNIX just suffering from its roots in this area?
Technology changes fast. Since I have been in school the computing world has become far more distributed and critical. Has security been dragged along for the ride as an afterthough? Are any new technologies promising? Are you suffering the same way I am?
Good security is hard, very very hard.
Apart of the considerations from the other answer, it is also because security is a balance between effective protection and effective ease of use. A system that is too complex to use due to its stringent security will likely to fail the user, which will drop it. Your role as a designer/developer is also to find the proper compromise between these two opposing forces, something which tend to introduce even more trouble.
I think that security is so hard because people feel inclined to do what they shouldn't, and try their best to overcome any barriers they find.
Only if this will power was used for something good...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Just want to ask for some opinions here. How do you feel about using a language (and/or framework) that isn't widely used in your location to write software for a company? For instance, I live in an area dominated by .NET, with the occasional PHP job. Let's say that I'm learning Python and decide to use it to write software for my job (I'm a "Team of One" so I can pretty much use anything I want).
Now their software is written in a language that pretty much nobody in the area uses or knows; if I were to leave the company, they'd basically have nobody to maintain/add to it unless they retain on me as a consultant. While that's really good for me, it seems a bit "crooked" - granted, that's how the business world works.
What are your thoughts?
I should mention that this is a very small company and I'm the only IT person, so I have full reign to choose our development platform. I'm not specifically using Python, but chose it as an example since my area is almost entirely .NET based; I don't care for .NET anymore though, which is why I don't want to consider using it. Also, the company is.. how shall we say... extremely frugal and wouldn't purchase the required resources for .NET (e.g. server licenses, SQL licenses, Visual Studio, components). I personally have an MSDN subscription but I can't use that for them.
Also FWIW there are people in the area who use the language I'm considering using (Ruby on Rails), but nowhere near as many people as .NET developers. It's not like I'm using something that only I know.
You may think that this approach is good for you. But in fact all this does is paint you in to a corner. The best way to get promotion - within an organisation is to make yourself unnecessary in your current position. That might seem like nonsense, but it is in fact true. Think of it like this, if it is essential to the company that you continue to maintain the python code you wrote for them, and they can't go to anyone else to get that skill, then they will continue to pay (maybe a little above market rates) to maintain that code.
If however, you write that code in .net where there is a plentiful supply in your area, then as the company expands and the code you've written proves successful, you will be able to hire people to maintain that code and you can move on to designing other systems. Or moving in to managing a team of .net coders - if that's your want.
Even if you want to leave, the best thing for your career is going to be to get the best possible reference. To do that, write them some code that is easy to maintain. Help them hire someone to replace you to maintain it. They will be grateful and recommend you as a consultant to their friends.
Code in something esoteric - for which there is little support in your area - and they will be saying to their friends on the golf course "no don't hire that guy, he wrote this system for us which does the job, but no one else can maintain it. We're stuck with him forever and now he's too busy to look after us properly!"
Do what's best for the business, not what might be of most interest to you - or appear that way on the face of it. You'll win out in the long run.
I think that you're responsible to decide on the language that's best suited for the job. That includes an objective evaluation of the merits of the language and framework, it includes your own personal skill with the language (since you're the one doing the work) and it includes maintainability by others. Only you and your company can decide how much importance to place on each of those.
For your own personal development, if your area is dominated by .net, why don't you want to get up to speed in that instead of Python?
From an ethical standpoint, I would not write something that could not easily be maintained by someone else.
A lot of responses seem to be a poor fit for the question. We're not talking about using an unapproved language in an environment with existing standards. We're talking about a situation where the poster is the entire IT and development department for his company.
It's certainly important to keep in mind availability of talent, but Ruby is hardly a fringe language these days. In an environment where there's only one developer, productivity is also a very important consideration. Being able to build and maintain software quickly and easily without a large team requires tools with different characteristics than a large team might require.
I think what's more important than whether to use Ruby or (something else) is to try to pick something as general-purpose as practical and use it for everything unless there's a really good reason to use something else. If you go with Ruby, stick with Ruby for your utility scripts, cron jobs and that little GUI app the boss wanted to automatically SMS the intern when he takes more than five minutes to bring him his coffee.
I think using python would be the right thing to do if it would meet the clients requirements, and save them money over the alternative. Whether or not there is a wide assortment of characters to work on the application down the road is irrelevant, unless they've specified this as a non-functional requirement.
As usual, using the best tool for the job at hand will serve you well.
It indeed is a bit crooked IF you use it only for that purpose.
However, if you use it because it IS the best solution, youre in the clear.
Also, they can just hire someone else who knows python.
My work ethics dont allow me to do something like this just to keep me in business.
My personal opinion is you should try where possible to respect the working practices of wherever you are - whether that's indentation style, naming convention, testing procedure or programming language.
If you feel strongly that a different language would be better suited for a certain task, then lobby to have it accepted (with the required re-training of others).
Purposefully leaving an app that no one else can maintain is very bad professional conduct, IMO.
We recently had a bad hire at my shop and he decided out of the blue he was going to use Perl instead of any version of .NET to do some simple reporting stuff (That could have just as easily been done in .NET). It was atrocious. I would suggest using the platform as specified and clearing any deviation with the people who run the joint...
Plenty of answers have touched on this, but here's my take based on production application support.
My company had a startup phase where code hustlers whipped up solutions in whatever the personal preference or flavor of the week was. Bad for maintainability and supportability.
Making a change is ok, though, as long as it's consistent. If Python is going to pave the way to the future, then go for it. Don't forget that the legacy .NET and PHP code still needs to be supported until end of life. Building yourself a hodge podge of platforms and frameworks will just create more difficulty for you on the job and the company when you're no longer around.
If you feel in your heart you are acting dishonestly, then you probably are.
No one likes a dishonest person. That can't be good for your reputation.
Do your best to choose based on what is actually best, not what satisfies some underhanded motives.
It depends. I did some of what would normally just be a bash script, in Java instead at one place. Why? Because they're all Java programmers and frequently have interns/coops coming through that may or may not know anything else (and may or may not even be all that great with Java).
Other places though tend to have more experienced programmers and I expect that they'll be able to figure out another language without too much effort. So, I would go with what's "best" for the project.
I agree with what mquander says above, but you may also have to be prepared to justify why you want to use this other language to your development manager. If he/she then agrees, perhaps the language could become more widely adopted within the company.
Think of it in terms of business benefit you bring to the company, now and in the mid-term.
If you can deliver something much faster using a different technology, and it still achieves the goals, I'd go for it - but I'd still let some other people know and respect the company's final decision. If however, it's purely for yourself, then I'd probably be a litte more careful.
I think it's a really bad idea. For you, it means there's no back up in case you want to have a day (or week) off. For them, there's no one else if you leave or are taking a day off. It's a well known ploy, and, honestly, might be reason to not keep you around.
However, this could also be a chance to introduce Python into the environment. You could teach others about it, and explain to management while it's a good third language to have at the group's disposal.
I used to think that you should always pick the right language for the job at work. I'm reversing my opinion though.
The problem arises when some other guy picks a language you don't want to learn. I am concerned that I might be the guy who picks the language no one else wants to learn. Just because I think that Erlang might be the right choice for something doesn't mean that everyone else will want to learn Erlang or respect my decision for using Erlang.
"if I were to leave the company, they'd basically have nobody to maintain/add to it unless they retain on me as a consultant."
Are you saying no one else can learn Python? I find that hard to believe.
New technology is often introduced in small projects by knowledgeable people and diffused through the organization because the small projects were successful.
Use Python. Be successful. Make your case based on your successes.
I had this same problem very often. Coincidentally, it was with those two languages you mention: .NET forced on me, when I preferred to use Python (among others). Could be the opposite, I don't judge.
I refrained to use Python, because of the reasons already mentioned in other answers. I did what I thought was best for the company. Using IronPython won't make your python code any more maintainable for an unexperienced Python programmer.
However, I left the company and now I work in something more in line with my tastes. I'm much happier. In this economy you may not have this option... but it will pass. Do the right thing.
Cheers.
There is a large difference between 'prototype' or 'one-shot' code and production code. For prototyping I use whatever works fastest, but I'm very clear about its status. Production code is written in one of the approved and supported environments.
The ethics is to use the best tool for the job. If there is a tool that takes you only 20% of the time to code vs other choices, and next to no maintenance, and easy to re-factor, you have a duty to pick that tool, assuming it's extensible as you may need in the business.
If you do a good job, hiring future people and training them in terms of HOW your workplace does business should be the practice of any growing business. They will be able to learn the code if they're the right person for the business.
In your case I'm not sure if you want to use Python, unless it has native .NET support to allow your .NET world to interact with it.
Other posters have made some good points, but here's one I've not seen: Communicate the situation to management and let them decide. In other words, talk with your boss and tell him or her that there currently are more .NET developers in your area, so that if you're hit by a bus tomorrow it would easier to find someone else to maintain your code; however, there are tools you need to do your job more efficiently and they cost money (and tell them how much). Alternatively, you could do this in Python or RoR (or whatever) and use free tools, but from what you know, there aren't currently that many people in the area who know those languages. I've used "currently" a couple times here because this may change over time.
Before having this conversation, it might be good to see if you can find user groups for the alternative technology in your area, and how large they are. You could also ask on listserves if there are people who know the alternatives in your area.
Of course, the boss may tell you to keep using .NET without any tools, but in that case it's their decision to shoot themselves in the foot. (And yours to decide if you want to find a new job.)
Regarding the question as asked, I see nothing unethical about it, provided that:
It is a freely-available language. Although I am something of a FOSS partisan, that's not the point of this criterion. It needs to be freely-available (not necessarily FOSS) so that it doesn't impose costs on the company and so that others will have the opportunity to learn it if you ever need to be replaced (or if they want to compete with you for your job).
You are changing languages for solid reasons and not for the sake of creating vendor lock-in (or, if you prefer to think of it as such, "job security"). Ethics aside, you really don't want to have a job where they hate you, but are stuck with you because you're the only one who can maintain the mess you've created anyhow.
In the particular case you've described, I would suggest that switching to RoR may be the more ethical choice, as it would be decidedly unethical (not to mention illegal) to use .NET if there are required resources which are for-pay only and your employer is too cheap frugal to purchase proper licenses for them.
When in Rome... do as the Romans.
You might not be the one who as to maintain this code in the long term and not everyone wants to learn a "fringe language" to make bugfixes or enhancements.
I migrated some VBA stuff over to Perl for processing at a previous job and increased the efficiency by several orders of magnitude, but ultimately no-one else there was willing to learn Perl so I got stuck with that task longer than I wanted it.
I did that, it was Delphi in my case. I think Delphi was used often however when i was looking for a job .... i saw 3 delphi job offers in my whole life. i also saw more java/j2ee/php offers that i can remember. i think its bad idea, with the time i wasted in learning advance delphi programming i could get better with j2ee and start in better company and maybe make now more money.
If they cant find somebody to maintain the app you will always do it and when you quit they will have to re-write it. i think consultant thing is not used often.
I used to be in the "use the best tool for the job" school, but I've changed my mind. It's not enough to just ask "how can I do this job the fastest." If you think you're the only one who will ever need to look at some code, there's a good chance you're mistaken. The total cost of introducing a new language into an environment is higher than you might imagine at first.
If you just need to produce a result, not a program, then you can use whatever you want. Say you need a report or you need to munge some files. If the output is really all that matters, say it's something you could have chosen to do by hand, you can practice using any language you want.
With the release of the MVC Framework I too have been in a similar ethical delema. Use WebForms or switch over to MVC Framework for everything. The answer really is you have to do the right thing and use whatever the standard of the company is. If you deviate from the standard it creates a lot of problems for people.
Think how you would feel if you were dumped a project on VB6 when all you have been doing for years is .Net. So these are the two solutions I have come up with.
Use your fun languages for consulting contracts you do on the side. Make sure the client knows what you are doing and if they agree go for it.
Try and convince your current company to migrate over to this great new language you are working with.
If you follow these routes you will learn your language and not piss anyone off in the process.
Ruby on Rails is certainly not a fringe language. If the company is too cheap to pony up for the appropriate licensing for Microsoft's tools, then you would have no choice but to find an alternative. RoR certainly would be a reasonable choice and if helps move your career along as well, then it's win-win for both of you!
You can develop .NET adequately with free tools; cost is not a good reason to avoid that platform. Ruby on Rails is becoming reasonably mainstream for building data-driven internet websites. You haven't even told us if thats the sort of software you are building though.
There is really no way with the information that you have provided that anyone can give you a single correct answer.
If you are asking is it ethical to do your work in such a way that the company is dependent upon you, of course the answer is no. If you are asking is it ethical to develop in RoR then the answer is "we don't know" - but my opinion is that probably it would be fine if its the right tool for the job.
Don't underestimate the ability of someone else to support your work or replace you though - if you do your work reasonably well once the solution is in place any programmer worth their pay should be able to learn the platform well enough to maintain it. I've debugged, migrated and supported a few PHP applications for example without ever hardly learning the first thing about PHP. I'd be lost building a new PHP app from scratch and would never even try but its no problem to support one. I think the same would be true of the languages you mention as well - they've got the critical mass that means there is plenty of books and forums etc. Of course if its written badly enough in any language then it may be difficult to support regardless of anyone's skill in the language...
So much discussion for such a clear-cut situation...
It's not up to you, it's up to them. If they're not technical enough to make the call, as it seems, then you have to make it for them in good faith. Anything less is dishonest, and I'm fairly sure that's not in your job description ;)
You've muddied the waters with all the wandering about in the thickets of personal motivations. The answer to that one is that your personal motivations are irrelevant unless and until you've formulated the business case for the possible decisions. If you've done that and the answer still isn't clear-cut, then sure, choosing the answer you like the best is one of the nice things about being in a position to make technical decisions in the first place.
As far as the actual question goes, to my mind if the most technically apt choice is also one that very few people work with, one of two things is happening: a) It's a good choice, and the number of people working with it is going to be exploding over the next 18-24 months (e.g. Django), or b) There's something wrong with my analysis. Technologies may be on the fringe because people are slow to adopt them, but that's generally not why they stay on the fringe.
If you find yourself thinking "I can't choose technology X, that'll make it easier for them to replace me!" you're in the wrong line of work. In almost any enterprise that's not actually failing, the IT guy who makes himself easy to replace tends to move up to harder and more interesting and more lucrative work.
I would not bring a new language/framework/whatever into the place unless they understood that's what I was doing, and that if I left/was fired/was hit by a bus, they'd have to find/train someone to work with it.
I have some experience in a contractor pulling in things just because he felt like it. In some cases they were the best tool for the job (in other cases they were not), but in all cases they were not the best tool for the team that had to maintain the code. In my case the contractor was a serious jerk who didn't really give a darn about anyone else and I believe WAS trying to make himself harder to replace.
In your case, talk to your bosses. If they really don't want to spend the needed money on .NET framework tools/libs, then switching to something else may well BE the right thing to do for them, long term.
And, as someone who has spent his career walking into the middle projects that others have already started - thank you for thinking before you add a new tool to the mix.
As part of a wide ranging job for a cystic fibrosis support organization, they'd also like a web site set up and I've decided on Apache running on Linux (due to its security and low cost mostly). Other than (fairly) static content, they also want a forum where people can discuss issues with the condition - it'll be attached to a hospital chain so there'll be plenty of medical staff there who know little about the web.
I can handle all the specific coding and Apache setup since I've done it before but I'm interested in people's opinions as to whether I should roll my own forum software or get a hold of some ready-built stuff. I've not had any experience with forum software but I could generate my own (initially buggy, I'm sure) in a month or so.
It'll require registration and login to leave comments (but guest access just to read) and I'd like it to be 'pretty' (excuse me while I remember damning customers for providing similarly vague requirements specs :-) but not necessarily infinitely-configurable with skins/themes/etc.
If anyone has some compelling reasons (and experience with specific products that can provide what I need), I'd be interested in hearing about them. Alternatively, does anyone have any 'gotchas' they experienced while coding their own forum software?
Advantages to rolling your own:
a non-standard custom-built system means you'll be less prone to "standard" attacks (e.g.: a vulnerability in PunBB) since bad guys tend to bother with exploit-hunting only on widely-deployed systems (more return on their investment)
absolute control over how your system works and looks
you'll learn a lot
Disadvantages:
you'll repeat mistakes other people have already solved
it'll take you longer to get up and running
long-term it'll be more maintenance (since you have to fix bugs & add features yourself).
you can't "leverage the community" -- if you choose an off-the-shelf forum that has a plugin system then there's a whole bunch of community add-ons that won't be available for your custom forum software.
There's a GIANT list of forum software on wikipedia -- there's most likely something in there that will suit your needs that you can get up and running quickly.
IMHO the old "don't build what you can buy" adage applies to this (well, the web 2.0 version is obviously "don't build what you can download"). Have a look around at the available forum software, pick one that covers 99% of your needs and tweak it to do the rest.
If you still want to build your own forum software that'll probably be a cool side project but if the job is to get a forum up and running, then go and download one - don't try to mix up the desire to do cool stuff and the day job unless the day job is just to do cool stuff only.
One of the best-kept secrets on the internets is a little gem called FUDforum, by Ilia Alshanetsky.
And yes, it's the same Ilia who wrote xDebug's original profiler code, improved the caching in MMcache, fixed several security bugs in libmcrypt, and who was the release manager for the PHP language from 4.3.3 to 4.3.6+. He is, as my friends in Boston would say, wicked smaart.
Because of this, FUDforum is robust, ridiculously fast and more secure than probably any other part of your web application will ever be. It comes with a neat install script and it has all the features you'll need.
Plus, it's not a high-profile target like phpBB or vBulletin, which means you won't have to worry about spambots constantly banging on the gates.
Having written my own forum software before...
It seems like a simple problem, but when you get into it, you find that there's a lot of little things that you'd like to do nicer, and it takes a lot of time. Mine was cool and all, and I did get paid for it, but if I was doing it over again (which has also happened), I'd use a customizable pre-made solution, and spend all my spare time doing something productive. :)
Forum softwares tend to have rather complex minimum requirements. A few things you are very likely to need do matter what you do:
Forum/thread/post hierarchy;
User system;
Security system (eg user/admin classes and all kinds of restrictions for users);
Gathering statistics;
BBCodes or some other minimized markup language (NEVER allow users to do full HTML);
File uploads and avatars;
Bans and other punishments;
CAPTCHAs;
etc.
Ready made forum systems provide this out-of-the-box and lots more. Setup is mostly easy too. Why do it all over again yourself?
My answer would be: don't reinvent the wheel, there are plenty of fora software out there. My preference would go for RForum if you need only that.
I'd say, don't waste your time. phpBB 3 is pretty stable, usable and feature-rich forum. We use it at work (for our internal discussions), and I really don't have anything bad to say about it.
I'd concur with most of the above posters that since you want something which appears fairly standard, why reinvent something that already exists?
Like any development, creating forum software is probably much harder than it looks! There will be problems solved in the existing software which you haven't even considered.
It's worth adding that if you do require any specific additional functionality, you can always build that on top of an existing solution anyway, which is especially easy if you have the source code (whether open source or commercial).
From the sounds of the website that you are building, there is the potential for the forum to be a highly useful and visible resource, it would be good to go with something that already exists, due to the quality of a lot of the products out there and the rich communities that surround them.
I think that vBulletin, although a paid for product, would suit your needs and give you a great base to build a community on.
vanilla is pretty bare bones and easy to configure, perhaps find a system which is easy to extend vs building everything yourself
Ready built until you have some really unique features needed that can be tied to money it will make you.