Port an IIS/ASP.NET site to LAMP? - php

I run technology for a medium sized company that is about to acquire another medium sized company. Our technology is all LAMP (Linux/Apache/MySQL/PHP), the company we are acquiring is all Microsoft stack (IIS/MSSQL/ASP.NET). None of the developers on staff currently do .NET nor have ever supported Microsoft server infrastructure. I'm having a tough time deciding what to do with the situation...
Do we port all the MS stuff to LAMP (not interested in going the other way for various reasons including my team's personal inexperience with it, the cost of licensing when we are trying to slash overhead, etc)?
Do we run both technologies in parallel with separate teams to support each and write a bunch of middleware so they can talk to each other?
Neither of these choices are optimal. Has anyone ever been faced with a situation like this and how did you proceed? Keep in mind we are talking about large infrastructure in both cases with high traffic volumes and fairly extensive backend systems. Any ideas will be welcomed.

I've never done this before, so take my opinion with a grain of salt. But I would suggest NOT rewriting an existing application. I mean, if it's a 1-page application which just tells you "Hello" when you click a button, then yes, rewrite it in PHP. But business applications that make money aren't as simple as that, and you'll be starting from scratch to rewrite something that took the other company x years to develop. Not to mention you'll have to support and maintain the application you're taking over, even while you rewrite it in PHP.
If you have smart developers on your team now, and they have capacity, they'll be able to learn ASP .NET. But it might be best to hire some ASP .NET resources to help your team learn it and bear the weight (maintenance and support) of the application you're taking over. Your teams can work together to find integration points between the two applications.
Faced with the choice of writing integration points, or writing an entire business application from scratch, I'd take my chances at writing integration points.

As part of the acquisition, are your company taking on the IT support team of the acquisition?
While eventually there are likely to be 'efficiency savings' that they'll want to make from consolidating back office staff, there is a strong argument to keep both teams supporting their 'own' systems in order to keep the lights on.
Then you need to analyse the overlap - do you end up with systems on each stack doing similar things. If so, look to consolidate onto the preferred platform and remove the other. Also look at (regardless of current skills), which stack best needs the business needs in the coming years. LAMP might be perfect right now, but there may be arguments for moving to .net to meet future needs. Then again maybe not, but needs to be assessed.
Is there a business need for the 2 sets of systems to share data? If so, at what level? Creating (web)services to encapsulate shared functionality and make it available to the other system may be one way to go (SOA effectively). Alternately you may need to share a backend initially and have .NET talking to a MySQL databases or somesuch.

This is a very complicated question.
If the two applications provide similar functionality, then I would run both side by side until the one you want to keep has all of the functionality of the other one. Then I'd switch the customers over and eventually throw it away. If the customers are receptive, switch them now.
If they are radically different apps then I'd most likely just maintain both going forward. Given that these are large applications, any rewrite is going to be painful and have a high probability of failure. It's best to just get used to the idea of having different tech stacks in house.
One thing, by maintaining both apps you will be in a better position to keep the acquisition as quiet as possible as far as the client base is concerned. Clients that already use an app typically only change horses if they feel the app they are using is no longer going to be supported. At that point, you can guarantee that some will leave regardless of how good the other system is.
If the acquisition is going to result in a change in marketing (for example, the other company's logo changes etc) then I would again suggest to just maintain both. The clients are going to be nervous enough as it is.
The point of all the above is that this is more of a business problem than a tech issue and boils down to the reasons you acquired the other company in the first place and how you will present it to the existing clients. If the company was acquired for the technology or their client base, then leaving it alone is a good idea.
BTW, I've done this a couple times. The only difference was going the other route from PHP to .Net.
In one case the app was relatively small, but had a huge base of users. We ended up using some URL rewriting rules so that the user base never even knew the app changed underneath them. It was a collection of web services.
In another case, the app was large, had a big user base, and had a very public skin. Again, we heavily leveraged url rewriting to preserve google placement as well as bookmarks. The biggest problem we had was development on the original site couldn't stop while we built the replacement. This presented a lot of challenges in that every feature had to go through both teams. In the end, the project took about 3 times longer than expected but because we had some highly skilled people on it it ultimately succeeded.

Related

What factors to consider when deciding when to split a project into microservices?

I'm currently working on an app that I've been developing for a while. There's plenty of different features, each independent from one another and varying in their immediacy towards the client. For instance, there's a set of files for users, a separate group for merchants, generating recommendations, CRON jobs and a set of peripherals (eg. search, chat, processing/uploading data).
At the moment I've separated most of them into separate services on Google App Engine and determined Standard or Flexible environments based on a frequency of requests along with the customisability that comes with adjusting the hardware for Flexible. They use Google SQL and Firebase frequently.
After a short break, I've come back to:
An expensive monthly bill from Google,
A returning idea - that I should merge these into just two services,
distinguished by Standard or Flexible.
I was planning on doing exactly that but decided to ask around first and hear what I'm missing. It seems juvenile to think these are the only motivators when deciding architecture.
As for further notes:
The codebase is mostly Swift, Python and PHP code,
I'm the only one managing it,
Costs are important as this is a self-financed project.
Edit:
I've further revisted https://cloud.google.com/appengine/docs/the-appengine-environments but it doesn't go into detail about how to consider where to split a project into microservices.
Thanks for your notes :)

CMS or Framework ground-up? [closed]

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 just got done reading this thread...
https://stackoverflow.com/questions/588888/best-cms-for-a-corporate-web-presence
Which was the closest thing I could find on the web. I too am looking to redesign a website for a corporation. I am the marketing director, not a developer.
I have researched this subject in many places. I won't say everywhere. I have read:
http://sunlightlabs.com/blog/2009/content-management-systems-just-dont-work/ and
http://www.webdesignish.com/the-best-web-development-frameworks.html
and dabbled at www.cmsmatrix.org and www.bestwebframeworks.com under the PHP area. I have read at least a few dozen articles from various places, some of them including the providers websites or forums.
I have read nearly as much as I can in the time I gave myself.. so with a little knowledge on all these areas I want to reach out to a community that has more experience.
Background: Manufacturer website, one location, no branches. One marketing/IT guy. Utilizes dreamweaver for all web editing needs. Knows ultra-basic html only for text and image placement and editing. I need to be pointed in the direction of a cost-effective design solution with either a framework or combination thereof, or a CMS that can give me what I need. The best example of what I want the site to look like would be a cross between tripplite dot com and logitech dot com, with some elements from a site like sonicwall dot com. I need an animated menu system but with images, so size customization is necessary. Simple animations for rollovers and click reactions so that users can tell when they have selected something. Page content does not change often, with most edits being to PDF documents. At present, I name all major documents (such as a 2011 catalog) with the same filename, and simply replace the document with the latest version via FTP. Nearly every other page will be a static page with static text and images. I might request polish on all other pages after the development is complete. Our site might end up being somewhere around 50 pages after this redesign.
It has been suggested to me to have the site designed in Wordpress by a pro, but everything I HAD read before reading the first-mentioned thread posted here said that I shouldnt use it because of content and bug issues. I believe that wordpress can provide a robust and feature rich corporate website that isn't just another blog or news site... I have seen a few examples like networksolutions dot com.
Project 1 is a redesign and new look. Project 2-9 goes through a parts library with thumbnails, build-to-quote system similar to a shopping cart but with no payments (and no PCI compliance), an e-page flip type catalog revision, and login portals with per user/entity content such as order history, order documentation/records and open-order production status and shipping information. We want it all. But where to go?
I have so far looked at for a CMS:
Wordpress, Drupal, Radiant CMS, concrete5 (and spoke with Franz a tad), and synType CMS.
To go the framework route with PHP:
yii, codeigniter, akelos, symfony, prado, cakephp and solarphp
The other ones I have heard many developers praising were jquery, dojo and django but im not sure yet if they are utilized in any other solutions that I listed.
Tomorrow I will be going through the definitions and such at bestwebframeworks to better learn about the once I had chosen and pit them against one another.
I would really appreciate any help in evaluating which platform would best suit me based on the information that I have provided above. Feel free to ask any other questions that may help narrow the list.
Thank you all in advance.
Before determining how to proceed, you need to as a few important questions -
Is your company in business to make money?
Do you ever expect potential customers to view your website?
Are you a trained designer with experience in usability and best practices?
Can you write maintainable, scalable, and standards compliant code?
Chances are, you should seriously consider hiring a professional for the job. A business website is often the first point of contact with a potential client and first impressions are hard to fix. If your site looks like your 8th grade nephew designed it with a full plate of mystery meat navigation and cross browser compatibility issues, you are likely going to lose clients before you even get a chance to talk to them.
There are likely a multitude of additional features and functions that your website could perform if you knew about them. A reputable professional would be able to assess the needs of your business and recommend website functionality to match. As they say, you don't know what you don't know.
My recommendation would be to beg and plead for a budget to get a website built by someone who knows what they are doing. A well built website will have tremendous ROI and pay for itself easily.
It looks like your needs are primarily front-end, I would recommend a JavaScript framework, like ExtJS or jQuery, I really like ExtJS. Then you could pair it up with some kind of python, ruby, php CMS back-end. Right now I am developing my website www.coffeedig.com (currently still in development) in ExtJS with a Django back-end. I picked ExtJS cause I have a lot of experience in it. I picked Django even though I had very little experience in python but python seemed like the best language to me. I all depends on your needs and your developers skills/experience though. Locally at my work we have about 3 to 1 ratio of developers to architects. It takes a lot of time to maintain and develop a CMS from scratch. So I would recommended against that. I wish I knew more on how large your development team was but personally I would give them a list and have them try the frameworks out and see what feels right to them. Also documentation and community support are two very important things.
Oh. I can see from your post your are trying hard to find a proper solution for your needs.
Since you will probably not be implementing / deploying the solution yourself, I can assure you that whatever option you choose, it is the developpers putting together the project that will make the difference. You can have competent developpers on your team, but if they have to use a tool they are not familiar with, the result may be deceiving.
The choice you need to make from what I read in your post is if you want to use a framework, where developpers will be implementing from the ground-up, or using a pre-built application ready made for content management (CMS) that can be tailored to your needs.
All the popular languages offer a multitude of frameworks that have all been tried and tested.
PHP has Zend Framework, Drupal, Symfony, and many, many more.
Python has Rails, Zope, Pylon, Django, etc.
All these could be viable choices, the main question is still, do you need an application with specific needs and business processes integrated that would be better suited with a framework to ease develppment, or do you simply need to have an easy way to show your products online and have an easy way to create and organise content? I suggest you not re-invent the wheel, if your needs are just for regular web-publishing, a content management system would reduce your costs.
Look around and search for demos of the solutions your are interested in, test-drive before you make a choice. And be sure to have a competent ressource available for the solution you choose, because in the end it is the developping teams competence with the product that will dictate the success of the result.
By the way, JQuery is a great library but is not what you are looking for, chances are it will be integrated in whatever platform / framework you choose! :)
My 2 cents, good-luck!
Frankly, it sounds to me that you have a mostly static website, with occasional PDF updates.
At the same time it doesn't sound like you have the skills to craft your web site by hand.
You also seem to have some familiarity with Dreamweaver, which a pretty scary powerful piece of software.
If it were me, I'd hire a solid Dreamweaver web designer that simply leverages DW for your site, and basically keep it static. With enough CSS and possibly JS work, the pages will remain static pages, and if you need to do minor updates, you're likely capable enough to do that on your own. Then simply sync up the site from your local copy.
The advantage of this is simplicity. Simplicity for you, simplicity for possibly future contractors, etc. If you're not planning on a lot of "interactive" features that require server side support, then keeping the site as static and simple as practical is a smart move.
Uploading a PDF takes simple training, not a CMS. And Dreamweaver should be more than capable front end to manage much of that for you.
Addenda:
I understand about your future plans, but those later phases are night and day beyond Phase 1. This first phase, this cosmetic and functional redesign, is essentially a marketing and branding phase. The skill set needed to implement it is quite different from Phases 2-9.
You can talk with your front end designer about the later phases, in terms of overall presentation, but the person implementing your front end will likely be quite different from the person implementing the back end.
Once you have finished with the Phase 1, the back end integration will be able to leverage the assets created when developing the later phases. None of this initial work will be "wasted". But you have the benefit of being able to move forward with your current toolset and releasing it early, while Phase 2+ are spec'd, developed, tested, and later deployed.
A CMS toolset, at this point in the process, is really a distraction.
In the end, the choice of toolset is really secondary to the person or team that you select to complete the other phases. It is good to be aware of the tool market, and the choices and their assorted advantages/disadvantages, but in the end what is going to matter most is the user interface that you as de facto maintainer are going to be interacting with day by day, and the ongoing maintenance of this system.
If you were buying a delivery truck, you no doubt would be selecting one based on a combination of how it fits your needs and overall cost of ownership versus shopping around to dealers "You know, I really like Volvos". You'll likely not care so much about how the engine works, or the truck is designed. As long as it starts and turns and stops like it's supposed to, with the costs you expected to pay, you'd likely be happy with it.
If you have a favorite, then fine. Likely whatever you pick isn't going to matter much in the end, assuming it's reasonably mainstream. If you don't have a favorite, then it's not particularly important. And if you don't have a favorite, it's not important at all for Phase 1.
But like a truck, it's more important to have a good mechanic. If you have a mechanic that likes Fords and is well experienced with them, you might want to seriously look at a Ford. Trucks are easy to find. Good mechanics, not so much.
Right now, Phase 1, it's about layout, color, and image. Things mechanics and programmers are notoriously bad at. Get this done now, with the right people, using tools you know since you have to support it short to mid-term.
Then look for some good people you trust to work with on the backend. They can use what you have done in Phase 1, and make it work with whatever tools they'll be using to do what, in the end, is most important to you.
Check out silverstripe, an amazing CMS probably better than most, most people just don't know about it. Amazingly easy to template and super easy to extend. It's also very powerful like unto Drupal. http://www.silverstripe.org/
Update:
Sorry guys didn't mean to make it seem like an ad. And no I am not affiliated with silverstripe I just really like it.

Recommended structure for high traffic website [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm rewriting a big website, that needs very solid architecture, here are my few questions, and pardon me for mixing apples and oranges and probably kiwi too:) I did a lot of research and ended up totally confused.
Main question: Which approach would you take in building a big website expected to grow in every way?
Single entry point, pages data in the database, pulled by associating GET variable with database entry (?pageid=whatever)
Single entry point, pages data in separate files, included based on GET variable (?pageid=whatever would include whatever.php)
MVC (Alright guys, I'm all for it, but can't grasp the concept besides checking all tutorials and frameworks out there, do they store "view" in database? Seems to me from examples that if you have 1000 pages of same kind they can be shaped by 1 model, but I'll still need to have 1000 "views" files?)
PAC - this sounds even more logical to me, but didn't find much resources - if this is a good way to go, can you recommend any books or links?
DAL/DAO/DDD - i learned about these terms by diligently reading through stack overflow before posting question. Not sure if it belongs to this list
Sit down and create my own architecture (likely to do if nobody enlightens me here:)
Something not mentioned...
Thanks.
Scalability/availability (iow. high-traffic) for websites is best addressed by none of the items you mention. Especially points 1 and 2; storing the page definitions in a database is an absolute no-no. MVC and other similar patterns are more for code clarity and maintenance, not for scalability.
An important piece of missing information is what kind of concurrent hits/sec are you expecting? Sometimes, people who haven't built high-traffic websites are surprised at the hit rates that actually constitute a "scalability nightmare".
There are books on how to design scalable architectures, so an SO post will not be able to the topic justice, but some very top-level concepts, in no particular order, are:
Scalability is best handled first by looking at hardware-based solutions. A beefy server with an array of SSD disks can go a long way.
Make static anything that can be static. Serve as much as you can from the web server, not the DB. For example, a lot of pages on websites dynamically generate data lists out of databases from data stores that very rarely or never really change.
Cache output that changes infrequently, and tune the cache refresh.
Build dynamic pages to be stateless or asynchronous. Look into CQRS and Event Sourcing for patterns that favor/facilitate scaling.
Tune your queries. The DB is usually the big bottleneck since it is a shared resource. Lots of web app builders use ORMs that create poor queries.
Tune your database engine. Backups, replication, sweeping, logging, all of these require just a little bit of resource from your engine. Tuning it can lead to a faster DB that buys you time from a scale-out.
Reduce the number of HTTP requests from clients. Each HTTP connect has overhead. Check your pages and see if you can increase the payload in each request so as to reduce the overall number of individual requests.
At this point, you've optimized the behavior on one server, and you have to "scale out". Now, things get very complicated very fast. Load-balancing scenarios of various types (sharding, DNS-driven, dumb balancing, etc), separating read data from write data on different DBs, going to a virtualization solution like Google Apps, offload static content to a big CDN service, use a language like Erlang or Scala and parallelize your app, etc...
Single entry point, pages data in the
database, pulled by associating GET
variable with database entry
(?pageid=whatever)
Potential nightmare for maintenance. And also for development if you have team of more than 2-3 people. You would need to create a set of strict rules for everyone to adhere to - effort that would be much better spent if using MVC. Same goes for 2.
MVC (Alright guys, I'm all for it, but
can't grasp the concept besides
checking all tutorials and frameworks
out there, do they store "view" in
database? Seems to me from examples
that if you have 1000 pages of same
kind they can be shaped by 1 model,
but I'll still need to have 1000
"views" files?)
It depends how many page layouts are there. Most MVC frameworks allow you to work with structured views (i.e. main page views, sub-views). Think of a view as HTML template for the web page. How many templates and sub-templates inside you need is exactly how many view's you'll have. I believe most websites can get away with up to 50 main views and up to 100 subviews - but those are very large sites. Looking at some sites I run, it's more like 50 views in total.
DAL/DAO/DDD - i learned about these
terms by diligently reading through
stack overflow before posting
question. Not sure if it belongs to
this list
It does. DDD is great if you need meta-views or meta-models. Say, if all your models are quite similar in structure, but differ only in database tables used and your views almost map 1:1 to models. In that case, it is a good time for DDD. A good example is some ERP software where you don't need a separate design for all the database tables, you can use some uniform way to do all the CRUD operations. In this case you could probably get away with one model and a couple of views - all generated dynamically at run-time using meta-model that maps database columns, types and rules to logic of programming language. But, please note that it does take some time and effort to build a quality DDD engine so that your application doesn't look like hacked-up MS Access program.
Sit down and create my own
architecture (likely to do if nobody
enlightens me here:)
If you're building a public-facing website, you're most likely going to do it well with MVC. A very good starting point is to look at CodeIgniter video tutorials. It helped me understand what MVC really is and how to use it way better than any HOWTO or manual I read. And they only take 29minutes altogether:
http://codeigniter.com/tutorials/
Enjoy.
I'm a fan of MVC because I've found it easier to scale your team when everything has a place and is nice and compartmentalized. It takes some getting used to, but the easiest way to get a handle on it is to dive in.
That said definitely check your local library to see if they have the O'Reilley book on scaling: http://oreilly.com/catalog/9780596102357 which is a good place to start.
If you're creating a "big" website and don't fully grasp MVC or a web framework then a CMS might be a better route since you can expand it with plugins as you see fit. With this route you can worry more about the content and page structure rather than the platform. As long as you pick the appropriate CMS.
I would suggest to create a mock app with some of the web mvc frameworks in the wild and pick one, with which your development was smooth enough. Establishing your code on a solid basis is fundamental, if you want to grasp concepts of mvc and be ready to add new functionality to your web easily.

Is there a high-level language for the web?

Preamble
To build dynamic web-sites, we have to master at least four languages:
HTML for the structure of web pages
CSS for layout and design
JavaScript for interactivity
A language for business rules or dynamic driven data
In addition, there's SQL for persistent storage, Memcache for sessions and caching, APIs for the many different content management systems. We should also consider interacting with OpenID, Facebook, Twitter, OpenSocial in building a web application, for it to be interesting.
All in all, it's an utter mess!
If you take into account two objectives:
Teaching web development to kids
Staying productive as a team
Question
What high level systems exist that unify HTML + CSS + Javascript + (Insert High Level Language here, PHP preferred)?
Background
I am a software engineer with 15+ years of experience as project lead and developer with technologies like Broadvision, Autonomy, Enterprise Java, and Oracle.
During recent years, I have focused on the developing community websites, using Drupal or PHP frameworks such as CakePHP. I like web development and enjoy the impedance mismatch between the technologies involved. Still the inevitable conclusion I come to is there must be a better way.
I am the father of two sons (13 and 9), and while I don't want them to become programmers I would like them to comprehend computers as more than gaming machines. I like to motivate them to tinker a bit with web development to express themselves.
Whenever I show them bits and pieces, I would love for them to have a toolset that allows them to create "interesting" results in an hour or two on a Sunday afternoon.
GWT goes someway towards being a high level toolkit, letting you write Java to produce Javascript.
"Links is a new programming language designed to make web programming easier. . . Links eases the impedance mismatch problem by providing a single language for all three tiers. The system generates code for each tier; for instance, translating some code into Javascript for the browser, some into a bytecode for the server, and some into SQL for the database."
At first I wasn't going to post this, since it's a research project, not a production system; but all these answers saying "that's how it is, deal with it" begged for a counterexample.
Web programming is an inherently multi-discipline craft.
The primary reason for this is because of seperation of concerns...the reason that HTML and CSS and JavaScript, SQL, etc, are not mashed together in one language is because they each have seperate goals, caveats, pitfalls, and strengths.
Can you imagine trying to debug a site that has SQL, CSS, JavaScript and PHP code mixed together in the same source files? You may have already had the misfortune of doing so. Sadly, there are literally thousands of sites written like this, and it is a complete nightmare trying to debug or add to such messy amalgamations of presentation, data, and structure.
All in all, an utter mess! How is one
supposed to teach web development to
kids?
I think the most important thing is teaching the fundamentals of programming and making them stick. Variables, logic, pointers, memory management, algorithms, data structures, etc.
When you have the fundamentals of programming, it's easy to work in multipe languages, pick up new ones, and easy to change with the times. This is an invaluable skill for something as constantly-evolving and trend-based as web programming.
In my opinion people new to programming should be started at lower level languages, like C for example. People should be tought the intrinsic, fundamental concepts of programming and should gain knowledge of what is going on behind the scenes before even being shown a higher level language like PHP or Python.
I think that this attitude towards teaching programming will have the effect of breeding better web developers as well as providing a barrier of entry that will weed out people that don't have the interest or intelligence. I think the result of this type of attitude will be better developers, better software, and ultimately more powerful languages and tools.
How is one supposed to teach web development to kids?
An army of kids in web development is what has degraded our profession since now just about anyone calls himself a programmer while it's getting harder and harder for us to get distanced from them and get decent pay.
Many languages and technologies to master? It's a good thing. Let there be some entry barrier to join the ranks of developers.
ADDED: By following comments I can see I have not made myself entirely clear. I say nothing about the age, be it 10, 30, 50 or 80. It's all about attitude. Whether a person understands and accepts the fact that there is much more to the profession than moving controls with a mouse in some designer or CMS. There is a lot of knowledge to be gained, including basics of CS, algorithms, data structures, databases, architecture, extensibility, maintenance, performance, scalability, usability, marketing and much more that belong to the workshop of a professional software developer. I a person is ignorant of those and doesn't make a move to educate themselves and strive to become more and more proficient, they do not belong to the profession. And let this opinion be biased.
The closest I think you'll get is .NET. There are many frameworks for many languages, but none that I know of that handle absolutely everything. Beside that you must not attempt to convince children that programming is a walk in the park. It's a difficult career, that requires a lot of study and keeping-up. We work with technologies that are here today, and gone tomorrow.
If you think about it, programming isn't any different than carpentry, or aeronautics. Just about any profession you chose will require you to learn a lot of different things to be better at what you do.
How are you supposed to teach web development to kids? Wow, that's a thorny one. How does one go about teaching them surgery, or intellectual property law, or civil engineering? Or for that matter auto mechanics, or plumbing, or general contracting?
Have you thought about popping in a Sesame Street tape?
Elmo doesn't like it when you trivialize his profession.
Software industry is suffering from unqualified individuals doing nothing but creating poor quality products and at the same time distancing this profession from becoming a true engineering discipline. This isn't something to get certified on. For the love of god, don't 'teach' anyone software development. Explain to them that making great software only comes out as a result of years of experience and wealth of knowledge of past and current technologies. The worst you can do is introduce yet another half-baked developer creating work for others working with them. Tell them to get educated. I know this isn't the answer you probably wanted to hear, but I wanted this to be read.
I think the problem with web development is that it was not originally designed for what it is used today. We build rich client applications inside a browser with HTML+CSS+JavaScript plus whatever serverside technology generates it. Yes, it works, but it's a pain, especially with those annoying browser incompatibilites. The existence of Flash and Silverlight proves this. They let you build your app with one single technology, still inside the browser. The downsides of needing a plugin for your content is obvious though.
The languages are the least of your worries. It's the problem domain that they work with that is complex. Using different languages actually makes things more manageable because a) It makes the boundaries explicit and b) the languages can be optimised for the domain.
Programming (PHP/JS) and document format (HTML/CSS) are 2 different things.
Learning to program in PHP and JS at the same time will also be difficult.
You should focus on HTML and JS on the client at start. You could then let them program javascript on the server as well. This will make it only one programming language, and focus on HTML over CSS to start with.
Once they've learned the basics of JS and HTML, you can teach them a more widely used server side programming language (like PHP, Ruby, etc) and CSS.
Django can take you part of the way through its cleanness. It is focused around productivity. Teaching is not easier than any other language/framework, but look at it this way: when taught this tool, your students are well equipped in their knowledge of how easy it should be. They will never accept Java servelets or similar nightmares after having learnt Django.
Check out Opa: http://opalang.org/
This is an up and coming web development technology. It looks quite promising. I have done a lot of web development over the past couple years and if I had to make a prediction which up and new framework/language/technology is going to be the primary way websites are developed in ~5-10 years I would say it will be Opa.
The documentation is great, the community is great, the tutorials and responsiveness to questions asked of the team working on the project is excellent. Overall they seem to have an attention to detail in regards to developing this new framework that seems to be unmatched.
Many technologies to master is not a good thing. We need a Visual Basic for the web, no matter what the elitists say.
You need different languages for different purposes. In most web applications there's actually quite a bit going on, so you need the different languages and solutions.
If the goal is to unify on a single language, you can do that. You can use Javascript on the server, and then build the pages using document.createElement() and apply styles to them directly to the styles property. And on the server, store your data directly in files with Javascript.
Obviously this wouldn't work out that well. HTML is not perfect, but there is a reason it is so ubiquitous-- it does what it does simply and well. CSS is both convoluted and too simplistic, but the underlying idea of defining overrideable rules to express your design is sound. And SQL may be a pain to understand at times, but expressing database queries this way is expressive and actually works pretty well.
That being said, I'm not saying there is or should be one architecture. There shouldn't be. Each project should use an architecture in line with its requirements.
On your next project try to simplify: do you really need a database? Can you combine the view layers to simplify, either using something like GWT, Applets, Flash or .NET? Do you really need to serve up your content in a browser (which introduces CSS, HTML and Javascript complexities), or can you just write an application?
I think your approach might need to be rethought. Take this for what it is, my opinion, but I would think this ordering might work better.
Top Priorities: (no particular order)
Develop problem solving skills
Be productive as a team
Next:
Basic Programming skills (PHP, Python, etc)
After they know how to solve problems as individuals and as a team they can move onto specifics such as:
Client/Server model
Markup (HTML, XHTML, XML, etc)
Styling (CSS)
Client-side scripting (JavaScript / jQuery)
Server-side scripting (PHP, Ruby, etc)
Build up their knowledge of what's involved piece by piece rather than jumping into the deep end off the bat - they'll be quickly overwhelmed.
At this point you can start to introduce things like file I/O and databases.
This will give them a fairly comprehensive skill-set. From here they can really start learning.
In addition, one may have to deal with SQL for persistent storage, Memcache for sessions and caching, APIs of content management systems, OpenID, Facebook, Twitter, OpenSocial etc. to build anything interesting.
These are whole topics unto themselves, you can't bite them off all in one chunk. Especially if you're taking these people from 0. Before you can build something interesting you have to learn to build something mundane.
HTML5 will probably be more in the vein of what you're looking rather than Flash or Silverlight but it's not quite here yet...Though support is building.
Baby steps, Olav - if this were The Matrix you could download all that info in one shot but we're not there...yet ;-)
For the moment, and near future, web development is the synergy of many different technologies working together to deliver an interesting user experience.
Well, that's my 2 cents
The multi disciplinary nature of web development is one of the things that makes it a joy to work in, especially in a team environment.
To work well as a team, you naturally come together with a group of people with a range of expertise, from UI/graphics people down to DBAs and sys admins. Even within a single layer of the group (for example back end programmers) each person generally specialises in a different set, for example some people may have more experience up towards UI, others down towards data.
I would take this variety any day, compared to working in a room of 10 java programmers all working on some middleware application.
If you simply want to teach them to write dynamic websites, set them going through the HTML tutorial on w3schools.com and once they're done, find yourself a decent looking stylesheet that they can include and set them going with PHP. That'll get them up and running as a hobby, and if they want to do more, they can start piecing together extra knowledge, like CSS and JavaScript.
Ruby on Rails goes quite a way towards unifying all of those, but for CSS it leaves you out in the cold (though there are probably a few frameworks for RoR that make CSS obsolete, but then you have another markup language, I think), and you still need Javascript (though it does write a lot of Javascript for you, and all DB code).
On the other hand, about your kids: programming is for programmers. On a Sunday afternoon to put something together in a few hours, you would need to know a framework, and buy some plugins, and get everything up and moving without much work. Something like Drupal or Joomla, where they sell templates (for Joomla you can buy packs of hundreds) and plugins to do all kinds of things. And when that fails, your kids should probably know how to go on ODesk and drop $100 to get something done on your framework. Learning to programming is good if you want to be a programmer. Otherwise, it's best to learn what you need to hire good programmers or buy good predone components, and have the cash to do it.
Last point about the kids: let them play video games. That is the best training that they can get for whatever the future holds in store on the computer side. Video games let you investigate, play, and relax with the computer. Once you have that, learning HTML, CSS, Javascript, and some application stack is cake.
angularjs could be an option. it is inteded for single-page-applications and runs on a nodejs-stack and does some template-javascript "magic".
example (template/code):
It binds(via auto-generated-client-side-js) the value from the input-field to the the heading(h1).
If you type something to the input field, the text in the heading gets updated.
And you don't have to write the frontend-js.
<input type="text" ng-model="yourName" placeholder="Enter a name here">
<h1>Hello {{yourName}}!</h1>

Selling a Script Built on a PHP Framework

There are a ton of PHP frameworks out there (i.e. Zend, Seagull, Symfony, CodeIgniter, CakePHP, Yii, Prado) that do a great job of implementing important pieces of a scalable/maintainable website, and I almost always pick one to start building client websites.
As of recently, I've started getting tired of providing constant development services to clients, and I'm looking at the possibility of writing more full-featured commercial scripts that can be resold over and over again in the hopes of finding that magical "recurring revenue stream" that you always hear about in fairy tales. Please note that I'm not talking about building extensions/plugins to CMS systems like Drupal or Joomla, but full blown website scripts.
So here's my multi-part question:
Is there any reason why I couldn't resell a script built on one of these frameworks as a full-blown turn-key solution (especially if the framework's licensing is something very flexible, like the BSD license)?
If not, why aren't others doing the same thing?
Have you ever seen a commercial PHP script that is based on a well-known open source framework?
I've wondered this for years, and no one I ask has ever really come up with a good explanation. It just seems like it is taboo to do so, and no one really knows why? I've seen commercial scripts that use third party libraries (i.e. jQuery, PHPmailer, etc), but never have I seen one built entirely on an application framework.
It really seems that a lot of people have missed the true nature of the question and even taken it as far as language debates (those never end well).
Is there any reason why I couldn't resell a script built on one of these frameworks as a full-blown turn-key solution (especially if the framework's licensing is something very flexible, like the BSD license)?
Assuming the framework license permits it then there's no reason you couldn't do this. You had mentioned Zend Framework so you may be interested in looking at Magento. While they offer a free community edition they also have a paid edition that works with the Zend Framework as well.
I recently worked with a file upload script that was offered commercially and it happened to be built on codeigniter (name escapes me at the moment).
If not, why aren't others doing the same thing?
My personal opinion is that it's a mix of quite a few factors really. The web based market for on premise applications (as apposed to SaaS) is already flooded with options and is starting to shrink in size. This makes less demand for an application that you would actually see the framework behind (with SaaS you most likely will never know what framework if any is being used).
A lot of the existing large players in the PHP market have been around for a while and already have their own code base that they have created and are familiar with. When you've spent years building your own libraries it's hard to justify moving to another framework.
A lot of the smaller players rarely educate themselves in proper application design and usually stick to procedural code. The big OOP features that exist in PHP today didn't come along until the 5.0 release. Mind you that was around 5 years ago but a lot of your programmers had started on their PHP tutorials and learning adventures before PHP5 was widely available and accepted on standard hosting accounts. As such most of our modern frameworks were not available CakePHP as an example didn't start until 2005. Zend framework wasn't around until 2007. These are all relatively new dates and I wouldn't expect to see a lot of commercial applications moving to them until the current generation of programmers that can write quality commercial applications age a bit (again just my opinion).
I have to heartily disagree with back2dos..
PHP's a solid, incredibly well used programming language for developing web apps. It can, of course, be used for commercial development and millions of people (me included) do just that. I'm not sure PHP bashing is really relevant here.
True, PHP is not compiled but if you really care about this you can use Zend Guard which can encrypt code. Personally I've always found open source code a plus point. Clients like to know they can get at the code if they really need to, it offers some reassurance.
There are lots of OS PHP apps, some great, some awful. Find a niche (like any business), something that has real demand, and develop for that.
So I think you're fine to develop commercial apps/scripts. Just make sure you give them decent support and documentation. You'll find people appreciate that and are willing to pay for it.
Finally on the point of your question, I agree they stand a much better chance of being used if they are based on an open source framework since you'll be opening yourself up to wider market. Zend Framework, as you may know, has a pretty open license which says you can sell anything you develop with it.
I think your most important question is point 2, why aren't others doing the same thing?
Well some people are. Vbulletin have been quite successful selling forum software, even though there's no end of free forum software available. I think their success can be attributed to a paid product, in part. As they're earning money, it's easy to fund further development. Open source, free projects usually require a dedicated team to keep development moving, as there's no money for motivation.
There's no shortage of turnkey solutions available on the web. eBay will have no end of $5 scripts available - they're usually rubbish and unsupported.
Where I work, we develop bespoke 'one-off' applications for our clients, but we're looking at selling the same applications to other clients as an opportunity to scale our business. In this case we're talking about large projects worth tens of thousands, but they're only sold to a handful of customers.
There's no reason why you can't sell a product for 50 or 100 dollars and make money - you'd just need to sell to 10, 100 or 1000 customers to start making a living from it.
And to succeed over the free open software? Produce something that isn't already available, or do something much better than what's available for free.
Finally, another model you may want to consider is software as a service. Take a look at Basecamp (37 signals) for example. Their product is not open source, you can't download it, but you register online and pay something like $10 for their lowest end offering per month.
They don't have to give out source code, and they have a solid recurring revenue stream. They have tens of thousands of accounts.
Yes of course you can sell it.
Most people don't just sell the scripts as normal people and businesses don't know what to do with them and so require a developer to install and configure the script. Developers won't then buy the script if there is an open source/free alternative. If the script performs a valuable task that is often done, then somebody is likely to copy it and create an open source version.
Your key to selling PHP code is to sell it as a service. This could either be the installation and configuration of it (like most web design/development agencies) or an on-demand version of it (think of any online business app).
My company writes and builds a lot of PHP software for businesses and as we get new clients and solve new problems we write our code in re-usable classes which we can then package up and sell to other clients without any further coding - which I assume is what you are trying to do. It's all possible, it just takes time and planning to write the software to make it re-usable for other projects.
Well in this case I think that codeigniter will be the best option because:
Don't need console access to configure
You just have to configure Database Connections
Fast, MVC, Cache, Logs, Good Documentation
Runs in PHP4, must of the people that buy this scripts have server restrictions to Upgrade PHP
Best Regards,
Pedro
As a PHP developer for over 5 years and selling scripts I never tried to developed a commercial script with a framework.It is just because Im not a good fan of any PHP framework.
Someone can say if you don't use framework you are a amateur as a developer.But I think its the a way any developer has rights to choose.
I think some companies don't use frameworks just because they just dont like to say this script based on 'ABC' to the customers.They want to boast about their scripts and only they can developed something like that.
I event seen any commercial web script that used any frameworks so far.
I can think of one reason against it: piracy. If your script is something a bunch of framework guys want, it will be pirated. If it is only for a rich niche, you can avoid this, but then you aint going to get any fairy-tale income.
It's not in the open source spirit of PHP. The trend is to give it away and then bill for the service. You might be better at marketing your script as such, and just charge people after they consult you and you hand them a script download and a manual.
i think, these are the key reasons, why it is not done:
the point of PHP was never building commercial applications (the original acronym means "Personal HomePage") ... it is an insecure, inconsistent language ... there are quite some good PHP frameworks ... nevertheless, the language is ... poor ... other server languages are cleaner, stricter, more secure, more powerfull, give access to a larger codebase and to better developement tools (notably java and the whole .NET stuff) ... i'd never use PHP if i had to built something really reliable ... (my favourite is this "overflow vulnerability fix" of chunk_split (line 1966)) ...
PHP is always open source ... ok, there are obfuscators, or even ways to distribute PHP in a binary form ... but the first is likely to break the code, if you do a lot of reflection/introspection, and the second usually requires some PHP extensions to be run, which is not really sexy ...
there are too many open source PHP projects around for any commercial software to succeed ... this was different before, but nowadays, you can simply get ANYTHING in PHP ... Typo3, Joomla, Mambo, osCommerce, PHPBB etc. ... frameworks as Flow3, symfony, CakePHP ... etc. ...
there are commercial sites running on PHP, but there is no good PHP software/framework i heard about, that i would pay for ... there's always a free alternative, and usually it is better ...
you will be having a hard time creating something, that is really worth buying ... and if you succeed, you will be having a huge community that will copy it, if it is worth buying ... either for personal commercial profit, or simply to provide a free solution ...
well, that's what i think ... :)
edit:
let me clarify my points
seems, i upset some PHP folks here ... that was not my intention (however i am quite disappointed, how biased you seem to be, given the fact that everyone contradicting me is a PHP developer and i seriously ask myself, what other languages you ever used) ... i myself started out with PHP on server side too and after moving through other languages, i came to see PHP in a different light ... explanation is provided ... whoever just does not want to read it, move on to point 2 ...i am not saying, PHP prohibits you from implementing a specific solution ... but it is being used to implement solutions it was never designed for ... it started out as >this< ... and it was constantly extended by many people, which produced:
an inconsistent API ... or does anyone else know a language, having a naming convention, where array_search, count and implode are all array routines? look at ruby, ecmascript or Haxe if you wanna see how beautiful core language APIs can be ... i'd say it's awfully designed ... but it's not designed at all ... it has simply been thrown together by numerous PHP contributors ... that's cool in the sense that you have a function for everything ... the point is, you probably won't find it ... ok, after a while, you will know it all ... probably ... but in other languages, for example, where arrays are objects, it does not take you long to know all core array routines ...
no real philosophy ... look at the languages mentioned above, look at Objective-C or functional languages, if you want, to see how consistent a languages semantics and philosophy can be, compared to PHP's "oh well, we'll just throw in another function, that'll solve the problem" ... also PHP arrays are the strangest data structure, i have ever seen ... something like a hyperpotent hash with internal order for keys and values ... and yet, it's not even an object ...
a lot of unsafe code (a lot of functions exposing overflow vulnerability or not being binary safe, or not escaping is documented, which could be used for XSS attacks) ... when i read an API reference, and it tells me what a function does, but the truth is, i have to take in account a lot of possibilities (long strings could crash my complete system or even inject ANY code, nullbytes could make escaping routines not work, but when printing out the string again, they disappear (this was a strip_tags vulnerability until not too long ago)), then that is what i call unreliable and dangerous ...
slow execution ... eaccelerator and similar extensions can reduce booting time signifficantly, but execution it self will still be slow ... the actual problem is, the language is far to permissive, which causes a lot of overhead ...
PHP was designed as a scripting language tying together a bunch of C functions ... it is often extended with further C functions, due to the fact that it is not the fastest language around ... this gives a nice speed up ... but how the hell do i know, whether a function is safe? who can tell me? i don't want to read through lines and lines of C to know ... so my two main points:
the API is a mess
what is behind that API can be a serious vulnerability for your application!!
in consequence, PHP is hard to trust ... i mean, i personally dislike both Java and ASP.NET, but i have to admit, they are trusted plattforms and trusted for a reason ... now problems arousing from the messy API are being solved by some frameworks ... but if a language requires a framework to wrap the core API in order to have something usable, that is a base for good, maintainable code, then something is wrong ...
how exactly do i use zend guard or ioncube on an arbitrary shared webspace?
really, best thing you can do, is write commmercial plugins for widely spread PHP software, but it seems this is exactly the opposite of what Lusid wants to do ... but hoping to find a niche, that is big enough that you don't need signifficant marketing efforts to reach you customers, that is small enough that you don't get crushed by copycats, simple enough to build as a standalone app and fits a number of other criteria that are prequisites for a commercial success, seems a little naive to me ...

Categories