I wanted to address some of the issues you're having, technically: The language can only talk ASCII.
That's not all that uncommon, I my postal address Mörkenstraße, breaks about 20-30% of the sites I use, it even recently broke my Amazon web services account, that I couldn't log in, or use their 3rd party email support system for help. Probably in this case you should print out a handful of copies of this article, and force your entire team to memorise it: http://www.joelonsoftware.com/articles/Unicode.html The topic of string encoding, and character sets isn't that complicated, once you "get it" - but trying to have intelligent conversations about it before you get it is just confusing, make no mistake though, that shouldn't be rocket science! It's something that Rails does quite well, all strings in Ruby (1.9.x and above) have an attached "encoding" attribute [sic] which can be used to remember, and change the encoding. To cut a long story short, the main issue here is to make sure *all* your systems speak UTF-8 <https://en.wikipedia.org/wiki/UTF-8>. That'll be a problem in Windows .NET environments (or earlier) as Windows uses a very wasteful, very "wide" (uses a lot of memory) version of Unicode<https://en.wikipedia.org/wiki/UTF-32>(right, nwruggers?). More on this below.... > RESTful web calls can only be provided by having the native web interface > wrapped in Classic ASP. A note on this, RESTful is often a term thrown around incorrectly, probably you just mean JSON over HTTP. > Sending JSON is possible with the latest beta version of the language, but > Structures passed in must be strictly typed. That's not such a bad thing, the latest new hotness language directly from Google (to which it seems everyone is switching) is the same, the core language supports a few primitive types, and one has to unmarshal JSON into structs. But that's ok… JSON is actually a pretty restrictive language (hash, string, boolean, number, array, null<https://en.wikipedia.org/wiki/JSON#Data_types.2C_syntax_and_example> ) It's slower than RAILS. That's an interesting one, I'm assuming you're referring to the framework and language stack as a whole, rather than just your app? Either way that's not great, since Ruby is slow as hell anyway! The latest changes to the web framework are possibly a mistake. "Never change a running system" I'm not sure if any of that really helps you, but it's just an insight into how (as a developer and architect) I read those points, perhaps then I can pick up some of what Ash suggested: It's going to be super important to get someone who understands how to work with legacy code, there's a couple of decent<http://www.svpg.com/engineering-wants-to-rewrite/> essays <https://en.wikipedia.org/wiki/No_Silver_Bullet> on this, put simply, this is *the most* difficult and painful exercise a business can go through. There will be years of knowledge trapped inside untested, no-longer-understood code, throwing that away, and starting a greenfield project might be tempting, but you'll lost business knowledge, you'll lose weird edge-case anti-fraud algorithms, you'll subtle order booking optimisations for some cases. Sometimes that lost feature will hurt the business ("What do you mean we didn't reimplement the customer emails??!!???!!"), sometimes nobody will notice, the business might never really have need the feature, and you'll move on with your business without that damaging legacy. Furthermore, you can't afford to stop all work, fire up a new text editor, and start working on a completely greenfield project. Your team (if coming from a .NET/ASP, or similar background) will not only be leaving the Microsoft development stack, but they'll be moving to foreign operating systems (developing Ruby, or Python, etc on Windows, just hurts.), foreign tool chaining such as Git, Rake, Capistrano, etc; and your operational team (if you even have one) will be moving to a Unix hosting environment. Even if your company can afford that financially, logistically you can't afford that risk, you risk throwing out the baby with the bathwater. And you'd be asking people to build a "big bang" re-launch of a system, in an environment they don't understand implicitly. Next, a word about what Ash recommended "replacing it incrementally" - this is tricky if you're mixing technology stacks, but one term for that kind of application is Service Oriented Architecture (SOA)<http://www.soa-manifesto.org/>, in short: build your app as a series of small services, with well defined boundaries. You haven't said what your app does, but in terms of a holiday booking application, for example one can break things into a few components: - The search data miners (talks to the flight and hotel providers) - The web site, forms, lists of flights, hotels, etc - The booking form - (some kind of anti-fraud check) - The "my bookings" area - The order process (books flights for customers, after they placed an order) - The mailing and confirmation system, ticket dispatch, etc - Business intelligence I've picked on this example, because I helped port that Perl application, to a predominantly Ruby on Rails system, and because people can identify with that. The interfaces to such a system become *interface contracts<https://en.wikipedia.org/wiki/Design_by_contract> *. These *contracts* can be enforced on a per-component basis, and usually, if distilled down to a bulleted list come down to something like: - JSON encoded as UTF-8 (which is a redundant statement, the JSON spec<http://www.ietf.org/rfc/rfc4627.txt>defines JSON as being valid only when encoded as UTF-8) - Over HTTP on some given port - If the service responds with a success status, then I will assume the data is safe (and forget it on my side) - … otherwise, I will make an attempt to re-send that data at a future point of time Beyond those four bullet points, everything about your business logic will have to be in there (did something fail, was it valid data, was it a 3rd party API error (payment gateway down?), etc, etc, etc) With those boundaries defined, or at least identified, your team could start to plan to replace one component with something written in another language, treat that as an experiment, and give yourself the freedom to try Ruby, Python, Go Lang, Node.js, Erland, Haskell, or whatever other language you feel like. It's not uncommon for systems to end up being hybridised, because different teams had different interests, or needs, or simply different friendship and drinking circles, so they felt like trying out a new language. These boundaries are the place where you can smooth out the differences, and weirdnesses in any given system, smooth out the weird Windows encoding crap, settle on a common interchange format that intentionally doesn't support language specific types, and standardise on a few core protocols. The software robustness <https://en.wikipedia.org/wiki/Robustness_principle>principle suggests that these components should be *liberal in what they accept, but strict in what they output*. When dealing with internal components, however it is wise to consider shelving this principle, and making sure that your components don't *drift*. Diversifying your language and framework stack will, at different times in your business' life seem to be both the best, and worst decisions you have ever made. I fondly remember working in a company with Perl, Java and Rails projects on the go (we were an agency, so no that insane!) - the knowledge transfer and opportunity to learn from (and mock) the other teams were invaluable; the shortage of team members for certain environments and unpleasant surprises and teething problems switching to another stack were memorable. If you manage to pull this off, you'll be in a situation where you have a handful of components, that together are a product, but alone are just components. Components which can move independently, and are treated as black boxes by the other components. You should be able to swap them out for experiments, and for testing environments where the booking system is a dummy app that just writes log files, for example. With these well defined, isolated components in place, if you decide technology *X* is a bad idea, then it should be simple to replace it. Lee Hambley -- http://lee.hambley.name/ +49 (0) 170 298 5667 On 4 July 2013 21:40, Ash Moran <[email protected]> wrote: > > On 4 Jul 2013, at 19:22, Sean Bamforth <[email protected]> wrote: > > > I can see where you're coming from, and believe me when I say that I > have serious concerns about doing a rewrite in a whole new language. But > the main impetus to this rewrite is not because the system is wrong. It's > because the language is wrong; it's old and you can't get developers. > > That's very important information and sheds a lot of light on the > situation. I didn't pick up from the discussion that this was the cause. > > In this case you'll benefit from someone with experience dealing with > legacy code, as I'm guessing the app has little to no automated testing, > and contains years of assumptions, business rules, and edge cases that may > or may not be still valid. If the app is of any considerable size you might > want to consider replacing it incrementally (perhaps like how you're > currently providing it with a REST API, as one example). This would demand > more skilled and experienced developers, but is considerably less risky > than a big bang release. > > Since you say one of your current difficulties is finding developers, it's > only fair to warn you that it's not that easy to find Rails developers in > the current market either. Most people I know have no shortage of work. If > the app is generating enough revenue for you to bid for at least one > experienced person in the contract market you may be ok. (I'm assuming at > least some of the existing developers will stay around to learn the new > tech.) Otherwise there is a case for broadening your technology options, or > you may find yourself in a similar situation staffing-wise, albeit with a > much better technology stack. > > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashmoran > > -- > You received this message because you are subscribed to the Google Groups > "NWRUG" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/nwrug-members. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/groups/opt_out.
