Is it feasible to support multiple applications of the same type that are all written in different languages? - multilingual

As much as we would all like to say it is a benefit to programmers to be language agnostic, is it really feasible to support multiple enterprise Web applications of the same type all written in different languages? Think about how complicated a CMS or e-commerce system can be -- now imagine supporting three different CMS platforms all written in different languages. I would hate to be known as a .NET or Java or PHP shop, but I also don't want to be the vendor who says they can support a solution they have never worked with, upsetting a client who wonders why we can't get something done right on time. Can anyone speak from experience on this? Does your company usually just suck it up, and try and to learn a new platform on the fly? Do you bill up-to-speed, or eat those costs?

I think it all depends on who your clients are and what they expect. I think knowing about different technologies is good, but really when you're hired by someone, they expect you to know what you are doing. Personally, I would much rather be known that I do a really good job with a certain type of technology and when hired, I get the job done well.
If you try and go after every contract without regard to what your core competencies are, you aren't going to succeed. You'll anger the people who do hire you and make mistakes, and you'll potentially miss opportunities where you can really shine. Sometimes you have to make compromises to pay the bills, but if you aren't careful, it can bite you in the end.
The large consulting firms I've worked with throw resources at it and hope they don't anger too many people. They mainly do this because they know that the people who work with the consultants and get angry when they don't get the job done aren't the ones making the decisions to keep them hired. To them (not all of them I know, but some definately), don't care if they screw up because they ultimately know they can convince the VPs and SVPs to keep them around.

To be honest, I think you tend to see this kind of thing happen over time, no matter how disciplined the organization is. It's natural for new methodologies to come bundled in the form of new libraries, frameworks, or even languages. Keep in mind that a .NET shop may well have been a ASP/VB shop at one time. They'll probably still maintain older systems for clients, because there's little benefit to rewriting everything from scratch.
I'm not sure anyone has the luxury to keep everything "the same," because language issues are minor compared to library or framework issues -- especially the ones you build yourself.

Related

Why is convention and consistency important while working with data fields/names?

The issue is about good practice with database, form fields, and coding in general.
We run a content providing platform, much like Buzzfeed and Wired. I am currently implementing the OpenGraph meta tags for each posts, so that the post links are nicely presented in external websites such as Facebook.
A co-worker from the marketing team insisted that we should put something else other than title in the 'title' field for marketing reasons.
I argued that the Open Graph meta tags should truthfully represent the content of the link, to conserve consistency and convention - that the meta tags should not be considered 'one-off's.
However I couldn't further explain as to why I should! I'm not really good with words myself.
Most of the quarrels involve other workers wanting to 'hack' with perfectly fine APIs or implementations and I have to convince them why it is important to at least stay in the safe zone while possible.
I know convention and consistency is one of the most important practice with technology but I think I just got used to the fact and forgot my university lectures on why it is so.
Could I get some thoughts on this issue?
A co-worker from the marketing team insisted that we should put something else other than title in the 'title' field for marketing reasons.
That's a valid decision. Your job is to help save costs or make money for the business. It is not your job to maintain the Facebook ecosystem as a whole. That's not what you are payed to do.
If you don't have any business reason why this should not be done you have no case. Such a reason could be that Facebook would penalize this or that this creates some development cost or risk.
If this is not a technical decision at all, and I see no reason it would be in the question, it's his decision anyway. In that case you need to inform him of the concerns that you see and let him decide.
You clearly try to work in a mindset that lets self-discipline prevail over short-term gains and quick-and-dirty hacks. Managing to do that is always beneficial in the long run, but convincing managers and/or sales people to let go of the short-term gain is never easy (on the contrary, most of the time it is simply impossible).
Just want to let you know that there are many, many IT folks who "feel your pain". Don't give up your laudable mindset too easily.
Convention in naming makes for source code that is more readily understandable by others who follow the same conventions. That in turn makes for less costlier maintenance. Consistency in choosing "appropriate" names for things has similar benefits. Saying on the tin what's inside (and not something completely different or something way too vague and ambiguous) is the best possible practice in computing, but it is the worst possible one in marketing.

Steps to take when planning and executing a new project (say mobile app)

I want to build a free app to become familiar with what is required, but I was always confused about the steps one needs to take to START a software project.
What are the steps required in order to develop a mobile app?
I will list some of the things I think should be done but I don't necessarily know how to do. Any advice, details and technologies you have to accomplish these steps would be awesome.
Decide which platform you want to develop. What are some of the pros and cons in this area for android vs iOS vs Windows8?
How to test the app - can you get free hardware to test with a well detailed app plan? Emulator?
Detail what you want the app to do and which functionalities you want.
Research if this app already exists. What are some areas of concerns in terms of not breaking the law such as patent infringement etc?
Setup a source repository such as git (google a guide I guess?)
Look at guides to familiarize yourself with APIs and write sample code to learn what you need?
Start the development and keep doing the above as needed.
Starting a software project can be as easy as start writing code. Most programmers will have an intuition as to what needs to be done and how it could be done. The other extreme of starting a software project is to start with talking to a client (or looking at the world) and figuring out what the problem is. I find that a thorough understanding of the problem you are trying to address with a project is already a long way into getting the project done painlessly. It'll give you a good understanding of what is required for you to call your project done.
So I guess point number one becomes: know what the problem is you're solving. Knowing this will also tell you if any existing app solves the same problem to a satisfying standard.
NOTE: I am not that familiar with the Windows 8 platform so my answer mostly talks about iOS and Android. The issues raised however are broad enough to cover large parts of the Windows platform.
Platform
Selecting a deployment platform is an important part of a launching a product, and a lot of other decisions depend on the platform. We are in the unfortunate state that two major mobile OSes exist that are separate in terms of code development and reuse. When considering selecting your deployment platform you'll want to think about the audience, and the (potential) sub set of the audience that is willing to pay for your application. Android might have to most devices out there but iPhone makes the most money (also for developers). However, remember that there are lots of apps out there and most developers don't ever make any (or not enough) money out of their apps.
Getting into app development with the aim of getting rich is going to leave you dissappointed. That's not very likely, then again someone always wins the lottery as well. It is a good way though to get employed and make some money that way.
Then there is the question of programming language (Java, Objective-C or C#). This is largely decided on what you are already familiar with, and if you aren't then refer back to the previous point.
Testing
Testing the product is a tricky thing. You'll have to start off with the emulator (which is usually provided with the development pack). Sooner or later however you'll have to test the app on hardware. I doubt you'll get your hands on free hardware but borrowing from friends and relatives is always an option. There may also be businesses that rent out test hardware to developers, if there isn't then I suppose that's one business idea to work on.
The platform choice will affect this also. Android is running on a much wider range of hardware than iOS.
Patent infringment
I don't know that much about patent issues, other than software patents are nasty. As a single developer I wouldn't be too worried about infringing on patents, the main purpose of them is to keep competitors at bay. What usually ends up happening is that big companies kill off competition with patent lawsuits, or they buy a smaller company that holds a nice collection of patents.
If you want to be on the safe side (meaning you own a company and are really doing this to make money) then talk to patent lawyers.
Code repository
A code hosting service like GitHub is fantastic in that it not only provides a place to have you code, but it also provides issue trackers for keeping notes on the functionality that is still missing or bugs that have crept up in your software.
The best places to start learning about Git are git-scm.com and the GitHub help pages.
Software development plan
Your last point explodes to a thing called software engineering. There has been lots of research into different ways of managing software development projects. The idea being that software development tends to be extended over long periods of time, the requirements of the project change during the project (as you learn more) and the project can involve anything from 1 to 100s of developers. Some way coordinating work between those developers (and all other parties involved like customers) has to be formalised, enter software engineering. The aim is to define a methodology and project structure that guides the development process and makes it more likely that the requirements are met at the end of the project.
Some models worth looking into include (Test Driven Development and other agile methods).
Finally I would add to the list of things that need to be done
Research libraries, note that this comes before familiarising yourself with the APIs of those libraries.
What software already exists that does a part of what you want to achieve. This goes partly back to the question of what platform to use. Apple has put a lot of attention in developing easy to use frameworks to support iOS app development. I am not that familiar with Andoird's or Windows 8 but the less code you have to write the faster the product will be done.
1 http://mobiledevices.about.com/od/kindattentiondevelopers/tp/Android-Os-Vs-Apple-Ios-Which-Is-Better-For-Developers.htm
There is only one step needed: Just start that project!
You are going to develop a free application, so it should be fun to do that. Choose whatever you like and keep going:
Make sure you are productive enough -- 10 Laws of Productivity
Avoid complexity -- Occam's razor, KISS principle
Let CI system do the boring stuff -- Machines should work; people should think.
Read books and improve yourself.
Please also avoid blind decisions. If you simply try several available options you'll eventually find the best way to achieve your goals. Do some PoC and decide. Nowadays 1-2 hours should be enough to start with any technology. This is the rule of maturity. You have your own goals, so it is better to avoid immature solutions.
Happy coding.
CPlayer I came to this forum with the same question since I am new to mobile app design and want to make my own app. I realize it is important to take certain steps in the correct order so that wasted time is minimized or eliminated. I did some research and came across two online sources I believe, if they are put together as one, will make one better source. The links are:
http://answers.oreilly.com/topic/2311-a-mobile-app-development-checklist/
http://mobiledevices.about.com/od/kindattentiondevelopers/ht/How-To-Create-An-App-For-The-Iphone.htm
Good Luck,
laroice

Salesforce: Developers view

We are in the process of deciding a route to take for a new CRM system. We've had Salesforce come in and give us their pitch and the developers have had a little play with it, made it do a few things we need etc...
It's hard for us to get a good idea of the pros and cons until we start to develop with it and if you start, you are tied in to a year contract for X number of users and it's pretty expensive as it is..
So, my question. Who has developed for sales force platform? how did you find the experience? would you recommend it as a good solution? Should we just continue with our ruby/rails/mongo systems?
Thanks!
The good news is the amount of customization you can do via configuration is amazing. The out-of-box functionality is very strong and you get a pretty nice security model and reporting system included.
Having said that, when you do need to do custom development beyond what the configuration can support, the pain can start;
-APEX is the most frustrating (modern?) language I have ever worked with.
-Deployment/Migration can be slow and painful (some things cannot be migrated, e.g. Approval processes)
-APEX is a rather immature language missing much of the concepts of .net or java
-Debugging is messy (log actually gets truncated at a certain length, no stepping)
Having said all that, SalesForce.com is a very strong CRM - 90% of the custom work you'll want to do will be really smooth and fast, the remainder will be extremely painful.

Advice on platforms/frameworks/languages/etc for a new project

I know this is not a programming question per se, but I wanted to get as much input from the SO community on a new project I hope to get started. The project is from being started from scratch and thus every decision for programming languages, databases, frameworks, platforms and what not are up in the air. I'm hoping to get your opinion on the matter, what you feel are the strengths and weaknesses of each option.
Database:
Currently I have the option of using MSSQL or MySQL. While I am leaning towards using MySQL because it is free and most probably has all the features I need. However, there is the possibility of having a lot of hierarchical data and the new hierarchical data type in MSSQL is quite appealing. Does it really simplify matters that much? Also MSSQL supports many more advanced SQL functions that may or may not be useful in the long run. While for development I can get access to Server 2008, multiple licenses as the development team grows and for production, are the costs justified?
Programming Languages:
The project will have a web based front end UI and a server based component that will do some heavy lifting.
For the web based UI, I was thinking of maybe doing Apache/IIS with PHP or IIS with ASP.Net in C#. I'd like to use a good framework to properly utilize good design patterns that should structure the code and development of the app. As well as make modifications in the long run easy to implement. I also want the GUI to look good and don't like the idea of buying .Net controls from component vendors. Instead I prefer the idea of using good CSS, and open sources like YUI and javascript to make the UI sleek.
For the server based component, I was thinking of using C#. I have no real development experience in C++ and I'd like good libraries and sufficient speed is good enough. However, while the web based UI and server based component is loosely coupled, there may be instances where the UI needs to communicate (call methods and what not) with the server based component and I want to pick languages/frameworks that will play nice with each other.
All suggestions on frameworks to incorporate are welcome.
Version Control:
I have had good experiences with SVN and a pretty bad experiences with TFS. I've never worked with GIT. Which do you think is better in terms of features as well as general developer familiarity. I want to pick something that other developers will know and not have trouble with.
I apologize if the questions are bit redundant or I'm not providing enough information or using bad terminology. I plan to edit and improve the question as I get feedback. Thanks!
EDIT:
Who: This would most probably be a startup formed of college students or junior developers. I want the project to utilize technologies that most people are familiar with or are easy to pick up.
What: I'd need hours and days to explain the solution. But in the end when you break it down, its a web based UI (think standard web app to just manage database data) that would be used to knowledgeable clients. The server based component would be very separate except for the fact that it should be able to communicate with the web app.
I can provide more information as required but I would appreciate an opportunity for users to answer and provide their ideas before you hastily close the question.
Obviously it depends a lot on specific requirements, but then again, even with those I probably wouldn't be able to tell for sure!
I've been working on a from-scratch project myself for a couple of months, and have generally found:
Choosing Microsoft for all the layers just goes down much easier (my subjective opinion). For example I would use C# for the UI, the back end, and use MSSQL for the database. Nothing at all wrong with non-Microsoft vendors, I'm no Microsoft fan-boy, I just struggle to get productive with unfamiliar tools. Depends where your experience lies though.
Database: In particular I've found that .NET and MSSQL go easily together. When I started the project I was using a PostgreSQL (because it's free, fully featured and has open-source warm fuzzies). However I abandoned it in favour of MSSQL simply because it was taking me too long to get database work done in an unfamiliar language with unfamiliar tools. Also, I'm not sure MSSQL is so expensive anymore, for example for a web application, MSSQL 2008 Web Edition is pretty damn cheap per-processor I think (only on SPLA licensing though). If you're concerned about database features in a free implementation though, personally I think PostgreSQL has a very full feature set, nicely standardised, and rapidly growing.
UI: I'm pretty inexperienced, but ASP.NET MVC looks far less painful to me than ASP.NET Web Forms. I like PHP too, but again I'd match the UI language with the back-end language, so would recommend .NET.
On frameworks, I'm immersed in DALs at the moment. I like Subsonic for lightweight data, NHibernate for heavy-weight.
I still have a long way to go with my project so perhaps I can only see the short-term benefits and drawbacks at the moment. But in general I would say: use the technologies that you're most comfortable using, as you'll be way more productive and the end result will probably be about the same anyway. If you want to learn new technologies though, and who doesn't? - go ahead, just expect it to take a lot longer.
Didn't want to answer 'cause it's so open ended. But a few points:
Money
First, check out BizSpark. That should take care of any money aspect for 3 years. For a service company, that means not only free VS Team Suite and Office and so on, but free Windows, SQL, etc. If your startup can't afford to spend a bit on MS tech in 3 years, it's probably a bad business. So that takes out licensing.
On a similar note, Sun has Startup Essentials. Could be interesting on the hardware side of things, but I haven't actually competitively priced them versus Dell/HP.
Software
It doesn't sound like you have hard enough requirements to say "oh, this slightly-less-popular software X is perfect for my domain Y and is gonna give me a very big boost". In fact, your project might not be like that at all. Maybe it, technically, is going to be a relatively plain application just pushing data around or whatever. You didn't specify.
For a small startup, personal productivity is probably going to trump any other argument. If your people are excellent in X, then that's one of your top arguments right there.
If you really don't have any particular system you're most comfortable with, be conservative. Stick with .NET or Java, as they'll give you the widest range of useful possibilities.
As far as things like OS and Database, I'm biased, but I think Microsoft will give you platforms that are easier to take advantage of than you'll find elsewhere. For instance, setting up load balancing, clustering, centralized authentication, managing servers (updates, events, etc.) is going to be easier to get going on Windows than it would be on another platform, assuming you're not an expert in either. Configuring SQL Server, even the advanced features, is a piece of cake. (Go time someone who knows neither: Setup a DB mirror in MSSQL and MySQL -- which is going to take more work?) Again, this is all predicated on you not having experts in a particular set of technology.
Don't mix -- whatever you do, stick with the platform. If you go .NET, MSSQL is going to work better with the data providers (or things like Linq-to-SQL). If you decide to do PHP, then use MySQL as everyone else uses it and you'll encounter less resistance. If you're not inventing stuff on the technical side, don't become an edge case.
You should pick the platform first, then the language that is best for that platform (if there is any choice).
One thing you should consider is the labor pool, and labor pool cost, for specific platforms and languages. Human Resources can often get cost metrics, if you don't have ideas already.
In my town, for example, .NET platform is much more expensive per Software Engineer than open source, because the .NET developers have a higher rate (40% roughly). C# is a little higher rate than VB.NET, but also tends to bring more well rounded candidates.
Just to throw in something totally different: How about weblocks as a web framework? It uses Hunchentoot as a server, which can run either standalone or with Apache. This is all done in Common Lisp. Weblocks can use cl-sql as a backend store, which can connect to many different RDBMs (MySQL, PostgreSQL, Oracle, ODBC, SQLite).

Can you use an object-database in a production system?

Object-databases are used very seldomly, albeit they offer a way to live without SQL, which is, I think, a benefit of its own.
Yet, I have seen them about never in production systems. Is there something fundamentally wrong with object-databases? Can I use a object-database in a production system?
Edit: So, maybe I should confess that I love object-databases. I cannot really get my head around why they are not used a lot more often.
Sure you could, as long as it was stable. The problem is the relative lack of high quality Object Oriented DB systems, as well as the fact that most people don't even know what one is.
db4o is being used a lot by many Fortune 500 companies (especially for embedded applications), so I wouldn't say that OODBs are not used for real-world production systems
There are production systems written using the GemStone OODB. It's a distributed, persistent Smalltalk system.
Heard of Cache? Used by EpicSystems for their Enterprise Health Record(EHR) product. Plenty of production shops using it.
The real question here is whether you require tooling to support your database or not. By tooling I mean reporting, data migration, data mining, etc. Do you need to provide self service reports? Heck, even reports with a fast turnaround time that doesn't require deploying new code? (Providing report functionality in the application is a real drag.)
There are countless tools available to perform these operations against traditional RDBMs. Against OODBs? I'm not familiar with any major products. Though, admittedly, I'm not an OODB kinda guy.
If you don't need those tools, they go for it. Otherwise, stick to traditional RDBMs. With current ORM technology, the pain of mapping objects to records is much less than it used to be.
The problem I believe, is that SQL isn't inherently a bad thing. It is very good at performing set based operations. From what I've seen, object databases work well when working with individual objects, yet fail when trying to do set based operations. Also, people are very good at working with SQL databases. It's easy to find people to work with them. Object databases are another story.

Resources