Over the years 'enterprises' have become quite entrenched in their opinions about software development. Many corporations even forbid internal development completely! Unfortunately, this means that using ruby can be quite a challenge for many of us.
This talk will show you how to navigate 'enterprisey' barriers to development by examining the following questions: What are some ways to really open the corporate decision-maker's eyes to what is possible with ruby? How can we sneak ruby into production without running into typical roadblocks? How can we use small simple applications to make a huge difference in our internal business processes?
As an in-house developer for a large corporation with a formal policy forbidding any application development I have been through the wars. I would like to help other rubyists 'beard the lion' and come through unscathed.
Nikos - That contradiction is exactly my point (see below for background). The talk will mostly contain tips & tricks on how to make internal processes better (more efficient) by using small applications to ease individual pain points.
A little background: I was a stake holder in a smaller company where we practiced standard agile processes and developed many workflow optimizing applications. That company was bought out by a large corporation with an official policy forbidding internal development. Now, I am in a position advocating that internal applications do not need to be taboo.
Vassilis - That is the direction I was going with it. I do think that it will end up being applicable to more than just the corporate in-house types, as the sorts of things that I intend to discuss will apply to many (if not all) businesses. I intend to analyze extremely common business issues often solved with manual labor (manual education tracking, giant Excel spreadsheets, drawers full of paperwork organized by customer, etc).
Hint: the key to breaking into this arena is to make life better for everyone involved!
It's not a "new world", it's a different, parallel world if not older than the one we (want to) live in. And there are thousands of people trapped in it. Whole companies in sections of the economy where the main expertise has nothing to do with software find themselves in need of computers and applications without actually having the knowledge or manpower needed. Strict regulation and draconian limitations on what can be used are common. Stiff processes, mountains of paperwork and general risk aversion abound. We all know that software in general and Ruby in particular can drastically improve effectiveness, efficiency and worker happiness. The trick is getting them in the door.
Now, is this a correct semantical edit of your proposal? Having been there (several times) I can relate and spend days swapping war stories. My fear is that it might just be the two of us and that the rest of the audience will just laugh at the academic knowledge of a world left behind :)
This is a new world that you mention and I don't get it: "in-house developer for a corporation that forbids application development". It's contradictory you know :D What exactly is your role then? I'm asking cause I'm trying to understand what the "suggestions" for people in your position are going to be and whether these apply to normal software development departments, that do have "enterprizey" constraints like using tools from well known and pricey vendors.