Last summer I learned HTML and CSS for a job, mainly through tutorials and a sort of "build this" method, that is, I'm given a goal and have to try to figure out how to build it myself.
Is there a place with some examples to teach someone with this method? My boss wants to get me going on PHP this summer, and I need to refamiliarize myself with it over the next week. Most people send me to Php.net to follow the documentation, is there another good method out there?
There is probably not a source online that lists projects that intersect with both your knowledge/ability and scope of interests.
I had success by implementing personal challenges based on stuff I wanted to do. Here are my examples:
A simple Twitter client (one text box, submits text to my Twitter account
Skills Learned : API's, cURL, webforms
A Facebook application that transferred your tweets to your Facebook stream (and filtered some)
Skills Learned : APIs, MySQL best practices (to store preferences), basic UI concerns, scheduled jobs (cron jobs), keeping a public timeline and estimation
A contest application that accepted user inputs and made a bracket that ran itself
Skills Learned : How to deal with user inputs from the web (scary!), accepting file uploads, image manipulation, user accounts (one vote per person), and how to make your own CMS/Backend for a webapp (I managed the whole contest from a panel I built for the backend)
The most valuable thing you can do is get a cheap webserver/MAMP/XAMP and just play. If you really enjoy the internet and programming, you'll come up with little tasks to try out all the time. Start whipping them up!
If you do the same thing over and over again, make your own library. Learn to include it in each project so you're not starting at scratch each time. Fail a little. Fail big!
well for my case i started my php learning (years ago) by a some basic built this systems,
start with:
guess Book
poll
news system
statistics script (how many visites per page, visitors by country,browser detection..etc)
board
CMS (content management systems)
if you understand french i can recommend a website where you can learn the basics and even more of php and mysql http://www.siteduzero.com/
good luck
PS: it's not that hard
My first real project (well, real indicating that I actually got paid to do it) was a very complex control panel for a large web hosting company. There were literally dozens of other control systems that needed to be consolidated into one 'intuitive' app. This included:
Network Monitors
Provisioning system / server control system
Support / Ticket system
Billing system
CRM
Webmail / Presence
Live chat (employee -> customer or employee -> employee)
Tie in with third party apps, like FreePBX
It had to be the most challenging assignment I have ever taken and actually completed. You can imagine how difficult it was to present a 'clean' user interface, given all of that functionality. Various components had to be able to talk to a central notification service.. E.g if you were in the network monitor, you'd be alerted that 3 new support tickets were waiting for you.
I'm not saying you should build something that elaborate, but building a control panel of some kind really helps you to learn how to avoid feature creep and teaches you how to conceptualize the end result at the beginning of the project. You'll end up with a lot of code that you can use on 'real' projects in the future, lots of experience with tools like Jquery and a firm grasp on how to build a good interface.
Invent (or think of) an industrial problem, then solve it. Acme Widgets needs your help! Control some motors, monitor some conveyors, graph supply and demand. Or, well, at least write code that could do it :) Then shrink it down into a mobile version.
Related
This is my first entry into backend development, taking mostly a design role in past projects. Im working on a personal project and have fleshed out what I feel is a logic of sorts. Just a few very basic user tasks broken down.
Core User Actions:
A user can create a new posting
A user can find posts from other users by tag, date created, and
other content. This is done in kinda a central search area. (Search
string: "Dog Saddle", retrieves posts with mentions of dog saddels,
dogs, and saddels)
A post's creator can be contacted from the post.
A user can delete their created posts.
I need guidance/suggestions with the following:
What data should I capture for users?
What framework is best for the application dynamics I've described? (ROR, Python, PHP ect. I'm a one man team currently)
Are there open source projects I may gain reference from?
I'm very dedicated to learning on my own, and can make use of good advice!
Thanks,
Given the rather generic requirements you've outlined and that you are just entering into the development arena, you should try an established framework. That way you won't need to write everything from scratch. You'll still have plenty of control, but the benefits of many commonly used functions, classes etc that will speed up your development.
Give something like CodeIgniter for PHP a try. See http://codeigniter.com/. There are a lot of tutorials online to help you get started. For example, see http://net.tutsplus.com/sessions/codeigniter-from-scratch/.
What you've described doesn't suggest a particular language at all. ROR, Python, PHP--you could use any of those to create what you've described. PHP is considered by many to have a less steep learning curve than ROR and Python, which is why I recommended it. However, there are frameworks for these other languages as well that will give you the same benefits as code igniter.
Recently I've read a number of articles talking about the idea of using "feature toggles" or "gatekeepers" to keep features hidden from users until the development is done. Facebook and Flickr both also talk about how they use this to test new features with a subset of users before unleashing them on everyone.
A bit of googling didn't turn up any existing PHP packages/tools that can be added to a web app to handle this type of thing. It seems straight forward enough to roll our own but no reason to re-invent that wheel if we don't need to. Are there any existing PHP tools to do this?
Articles
Feature Toggle by Martin Fowler
Flipping Out on Flickr DevBlog
Clarification: The part of this that I'm looking to see if it exists is the admin panel that controls which users can see the new features. In Flickr's example, they can turn it on based on the host. In the Facebook example, they add functionality such as limiting a feature to 5% of users, only TechCrunch users or only East coast users.
The admin panel seems crucial when you have 200 turned on features, 10 features that aren't quite done yet and 3 more that you're demoing for some users.
if (user_can_see_app()) {
show_app();
} else {
dont_show_app();
}
I fail to see why a package would be required for something so simple.
I've wrote a micro service for feature toggle pattern, called Bipolar:
https://marinho.github.io/bipolar-server
It is written in Python but that doesn't matter because it is an external API and Admin interface, so, all you need is to write a PHP client for it. We have used it in production for a while but only worked on public release and documentation recently. For JavaScript support it can push notifications using Webhooks as a basic URL call or via Pusher event.
I am bit missed after many years with no contact with PHP, but I can help you to write the client if you are interested.
I hope that can be helpful.
The easiest solution i found is to have the feature toggle state stored in some remote location that can change easily (turn it on/off)
I found it easy to have on GitHub a repo holding some JSON data with the feature toggle's state, later on you can change that state on GitHub (from phone/pc etc...)
your php code needs to fetch the JSON and make a decision from it ...
you can look at the blog post about how to achieve this:
http://www.nimrodstech.com/dead-simple-feature-toggle/
it shows a code snippet of how to achieve this in a simple way.
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.
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.
I currently work in an agency and have been considering trying to branch out on my own. In my current setup, whenever I interact with a client, it's at the later stage after they've hired us and after someone from sales did all the front work with them. I suspect it's very different for developers who deal with clients directly.
My question is how much explanation and training do you have give to clients before they're on the same page with you? How often for example do you find that clients don't understand the concept of a content management system? What other similar "basics" have you found that they don't understand?
They might not know the buzzwords, but they understand what they want and (usually) what they want to do. It is nice to use terms so you and the client can communicate easier, but don't beat them over the head with terminology.
They don't want a "CMS" they want the ability to add/edit/delete pages in a simple UI and have them displayed in the same style as the rest of their site.
Communication is getting ideas and concepts across, not necessarily "educating" your clients.
There is no definite answer to that. Clients differ. Some have more affinity for and experience with technical things and jargon and some dont. Some dig buzzwords, some prefer plain english. You have to adapt to the individual client. The most important thing is finding out together what they really need - not what they think they need. Or As Henry Ford put it:
"If I had asked people what they wanted, they would have said faster horses."
One of the biggest misconceptions I have come around regarding CMS is clients tend to underestimate the effort they have to put into it once they have it. They think (or have been told) a CMS is easy and cheap: you can update your content yourself and you dont have to pay the expensive agency to update your site anymore. Sounds brilliant, but it's a myth.
Clients have to understand that Content Management is a process that requires a lot of work. It's not just some technical thingie you install. That's only the smallest part. It also takes time to know the CMS and it takes practise. Use it or lose it. A CMS has to be used by someone and those people have to understand the aims of the website. They have to have a skillset in editing and writing and - if you allow extensive designing - design. Otherwise, the CMS a) wont be used and/or b) will contain poor content and/or c) look like crap.
Despite being six years old and published on April 1st, I find most of the arguments in Why Content Management Fails still very valid and good to consider when working with clients who want a CMS.
I have worked on both sides, with clients as the resident coding troll and with software shops as one of the programming grunts. And on most jobs the whole engagement is often reduced to the software shop trying to sell a product, do some cursory customization, and then get out as soon as possible. And I don't blame them. I often found that clients:
Didn't know that that content on the web can be copied and pasted.
Thought that a product, i.e. the CMS system itself, can somehow divine content on its own.
Were convinced that the whole process is either an IT problem or the consultant's problem, i.e. they will ask you to keep the content updated for them.
That is to say that most clients will have an intuitive understanding of what a CMS can offer them, but they won't fully realize what it will require of them.
If your agency wants to expand into including a CMS as part of your total offering, which seems to be more about design and content as your question implies, I think you can stand to benefit your clients a lot more, particularly if you're up front with them about what they will need to do.