As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am making a very specific "control panel" sort of thing to organize information, record statistics, deliver alerts, and things like that.
My initial plan was to make it using CakePHP. I tried Cake, and although I thought it was really awesome, I really hated it due to the fact that it's "automagic." I didn't like how it did all this stuff without me knowing. Yesterday I switched to CodeIgniter, because a friend told me to try it. I like CI much better, however using a PHP framework just doesn't feel right. To me, it doesn't feel nearly free or flexible enough.
My question to you:
Should I continue trying to use a framework, or should I construct a 'semi-framework' that makes certain things easier (layouts, form validation, localization)?
Might I add that I already have a secure authentication system created (well, I THINK it's secure, but that's for a different discussion :P) that would be fairly simple to implement on this site.
Should I continue trying to use a framework, or should I construct a
'semi-framework' that makes certain things easier (layouts, form
validation, localization)?
I think the big issue here is whether using a framework is making your life easier or not. Frameworks are designed to simplify coding by giving you a powerful base to work off of in your own code. If that base is helping you by reducing the amount of code you need to write and the amount of maintenance that goes into it, then yes, I would strongly recommend you use a framework. If the framework is making your job more difficult because it is not well suited to your needs and is not reducing the amount of work you need to do overall, then I would strongly recommend not wasting your time with one.
Just like you'd stop using a dishwasher that isn't helping you wash the dishes faster or better, go ahead and stop using a framework that isn't helping you code faster or better.
It depends on your site. If you have large site with dozens of pages, better use a framework. But if your site is tiny, there is no need in using it.
Try combining Zend with NuSphere PHPEd IDE. Zend is a generic all-purpose framework which allows you to go as hardcore as you desire and it has tons of examples and documentation. PHPEd will enable you to do really nice debugging, even inside the framework code, so that you will feel in absolute control.
On the other hand, reinventing the wheel is never a good idea. You will never be able to get all the form validations right all by yourself and the amount of testing for all this code will make you stay in the office, on Tuesdays, during the graveyard shift :)
It might be a great idea to spend some time reading about some open-source projects, like Magento, so that you can observe the true power of generic frameworks, before trying to write your own.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been advocating using Scala at my company. One of my co-workers forwarded me this link tonight
http://blog.joda.org/2011/11/real-life-scala-feedback-from-yammer.html
I was hoping to get some constructive feedback from the SO community about this. I don't want this to turn into a flaming thread, but if there are legitimate concerns floating around out there I think it would be beneficial to discuss possible reasons and best practices that can avoid others falling into such traps.
I will say that I have been loving Scala and have not run into any of the problems that are mentioned. My application is also not very hashmap intensive, which appears to be where a fair number of their problems came from.
[Edit - apparently I need a question!]
The question is, do you think that the problems described are systemic to Scala, or more unique to their environment? If they are systemic, are there some good guidelines for a company that is just getting started with Scala to follow so that they don't end up in the same boat in 2 years?
Issues Described
Language Complexity
Systemic issue. Scala is unlikely to get less complex, whether or not that is a problem depends on the developers that are working with it. For me, it is complex enough to keep me interested and engaged, whereas pure Java can be mind-numbingly boring. My suspicion is that if Scala is way too complex for a particular developer, it is unlikely they're going to be top-notch dev when it comes to Java as well.
Community
So this one guy says the only way to do this is with a bijective map
on a semi-algebra, whatever the hell that is, and this other guy says
to use a library which doesn't have docs and didn't exist until last
week and that he wrote. The first guy and the second guy seem to hate
each other. What's the Scala way of sending an HTTP request to a
server?
That quote is pretty funny, but this is obviously a non-systemic issue with Scala. His main complaint about a lack of consensus regarding best-practices is relevant to all up-and-coming languages. I think Java developers have been spoiled in a way -- having gotten used to being part of such an enormous community where pretty much everything has been done before and possibly already standardized.
Build Toolchain
Another non-systemic issue.
Performance
This one does worry me a little bit and I can see getting frustrated very fast having to uncover previously unknown performance gotchas. I suspect for years to come there will be some pretty big performance penalties depending on how you use certain aspects of the language -- so people will have to exercise caution and make their own analysis regarding each project's performance requirements.
I concur with his sentiments here:
Despite the fact that we're moving away from Scala, I still think it's
one of the most interesting, innovative, and exciting languages I've
used...
And finally I would urge people to read Stephen Colebourne's blog with some degree of skepticism, because his personal disdain for the Scala language seems a bit oversize relative to the arguments.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have a project need to start in a week; Joomla and Drupal are both in my candidates list. Performance is the key to my project: Which one do you think is better for me?
Drupal is better supported for high load sites than Joomla. It is also much more flexible. I've built sites on both and I wouldn't touch Joomla again tbh. Companies like Turner Media run sites like "Cartoon Network" on Drupal, albeit highly customised and thoroughly beefed up.
If you're using Drupal 7 it has a lot of these customisations built into the core and so will absolutely fly along on all but the biggest projects.
Check out the Drupal High Performance Group if you have any specific questions.
http://groups.drupal.org/high-performance If you can't use D7 because it doesn't have the modules you need, then D6 is pretty well supported for large site now, would recommend looking at PressFlow as a distribution - it's coded from the ground up for high performance sites.
TBH your hardware setup will have more of an impact on performance. If you're running your site on some 2-bit shared hosting then it'll be a pig - if you're running on an array of dedicated servers with PressFlow, Varnish caching, dedicated database servers etc, it'll fly.
Well, others have spoke up for Drupal, I have to say I'm a big fan of Joomla.
If you're new to CMS Joomla has much less of a learning curve - and despite statements to the contrary - is just as capable as Drupal for running large/popular sites.
There are quite a few similarities between the two.
For more 'programmy' folks, they seem to really jump into Drupal and like it because it requires a bit more knowledge in that arena to use out of the box. Joomla can be very programmy oriented for the advanced users, or it can be simple to use out of the box (a bit unlike Drupal) for the average user who just wants a nice clean site up quickly.
Both of them have little things that make them unique, but both are completely capable and very similar 'under the hood'. If you do some research between them you'll find in very specific testing - each out performs the other for various specific tasks. If those tasks are important to you, then weigh those tests appropriately.
If you're just a general user looking to make a great site? Joomla has a much more simple/straightforward learning curve and Drupal is more 'programmer' oriented out of the box - but both are good solutions.
I personally choose Joomla - I'm familiar with the framework and can make any sort of custom template/site up and running in short order. Drupal seems to always make me invest more time in customizing modules, having to figure out exactly how to get modules to do what I want them to, etc. Joomla has a huge community (thousands of modules) that typically have a lot of parameters out of the box to get them to work as designed.
Just my $.02! Either way, you won't go wrong if you already have a bit of php knowledge.
That might be a question depending on several factors. Mainly which caching options are offered (usually by 3rd party plugins) Im not much of a fan of Joomla. By your question it sounds like you are new to building a CMS. Have you looked into Wordpress? Very easy to work with and tons of plugins. I would go with that or Drupal.
I realized in the end I didnt really answer your question that well either. To be honest I wouldnt focus on the performance of the CMS you decide to use. There are so many tweaks you can do to apache, IIS, lighttpd, nginx, etc... Also disabling modules and running a lean DB will help out greatly. But since we all like pictures links and quotes here is one that should help http://buytaert.net/drupal-vs-joomla-performance
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I work in a company where, since I arrived, I had full freedom to use whatever Microsoft technology, pattern and tool in order to develop my applications.
I started to develop all the applications with ASP.NET MVC3 and I currently have 5 applications deployed and working.
The other day I had a meeting with my manager to review all the applications and he realized that my code was completely different than what he expected. He basically realized that I do not use Web Forms and that I use MVC instead. He thought he was just some component/tool and not a totally different approach to programming. He was curious and he briefly studied what ASP.NET MVC was.
After two days he said that I need to convert all the applications to Web Forms and use just Web Forms from now on. He says that MVC resembles the old asp(that for certain aspects is true) and that it takes longer time to develop the application and makes people confused when there is the need to change/maintain the application.
I think it is not true because, after a steep beginning, I got used to the magic of MVC and it eases development, componentization and maintenance of applications.
I said him that Web Forms is too coupled UI/Logic/DAL, after a while the code becomes unreadable and it jeopardizes unit testing. I also shown the possibility to replace the old GridView(one of his main concerns) with the jQuery or MVCContrib grids.
There was no way to convince him. Both for work and personal development I do not want to take a step back to Web Forms, therefore I kindly ask you to tell me the most important points that make MVC "superior" to Web Forms.
Thanks
Unfortunately, it's not uncommon for a manager to give a business-speak-laden version of "I don't understand this, so I want you to do it my way instead." This often stifles progress. (I've actually left jobs in the past for this very reason, managers who refused to allow any development that they personally didn't design.)
However, you also need to keep an open mind on the subject. He may very well have good reasons for this. Supporting the code is a big concern, and while I agree that it's easier to write clean and de-coupled code in MVC, at the same time he might be seeing a market where it's much easier/cheaper to hire farmed out developers at low cost to support a WebForms application. He may have a stack of resumes in his drawer that paint a very different picture between WebForms and MVC.
The best thing you can do, really, is approach both paradigms with a completely open mind. Understand that the rumors of WebForms' demise are greatly exaggerated. So if you really want to convince him of anything, then you're going to have to present a proper and unbiased comparison.
Start with a simple pros and cons list to compare the two paradigms. Make sure you don't skip on anything. If he has pros for WebForms and cons for MVC that you tried to ignore, that'll hurt your case. Evolve that list into some examples, demonstrations, proofs of concepts, etc. Make your argument tactile, give it numbers and tangible values that mean something real to management beyond just "this is a better development strategy." Quantify it.
If you approach this with an argument that says little more than "well, my way is better because it just is" then you're not going to get far. Even if you have a point to make, you have to successfully make that point to him. You have to put it in his language.
This is really less about which development strategy is better and more about communication and clarifying your ideas. After all, if you can't defend your position then from his perspective it's not a good position.
And if you fully clarify and quantify all of this, and it's critical that you keep an open mind about WebForms, then what you've done is given him the information he needs to make an informed decision. That decision may not change. He may still insist on WebForms. But it's his decision. What you're doing here is presenting him with all the pros and cons, all the costs and benefits (both immediate and long-term in terms of re-writing what you already have and ongoing support and all of that). If his decision turns out to be wrong, at least it will have been his informed decision. You won't have kept anything from him.
In the end, he may still insist that you do things the way he understands them. Some managers are like that. But take this as an opportunity for your career to master the art of presenting an argument. It won't be the last time you find yourself doing this.
I would search data or survey result showing superiority of MVC projects rather than telling him how good MVC is. MVC is just more productive way of creating & maintaining quality software. One thing I would like to add is that since UI is completely decoupled with biz logic, it is a lot better to automate code production with code generation tools such as T4 and MVCScaffolding.
WebForms was created to make it easy for WinForms developers to move to web. ASP.Net MVC's main benefits are that it separates out the Model (data), View (HTML,CSS,jQuery) and Controller (logic and routing). This allows different people to work on different parts if needed (separation of concerns). It also is much closer to a true web model, designing using HTML directly rather than this being abstracted away by ASP.Net User Controls. Obviously, in MVC, you have the HTML helpers and can make your own custom helper extensions as well as using DisplayFor and EditorFor templates.
The bosses argument is that many developers will know ASP.Net but not MVC, so it will be easier for others to work on it. However, MVC has been out a while now and many keen developers will have already picked this up or can do very quickly. It's a very clean and powerful way to develop web applications very quickly and easily maintainable in my opinion. ASP.Net of course has its advantages too but you asked "what makes MVC superior" so I've just argued a few benefits of MVC over ASP.Net. This is by no means an exhaustive comparison and hopefully others will add their opinions too.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
How has the current economic downturn affected the way you/your team works ?
I am tending to do more enhancements, compared to brand new development a year or so ago.
This question came about during another pub conversation where we were discussing if it's good to work on supporting applications or working on new projects - which is more stable, for the foreseeable future, with companies cost cutting in all areas..
I mainly work on extending existing applications. I would say this is probably the safer of the two options also. More than likely people are already using the existing applications, and because of that you don't need to convince them it would be advantageous for them to start using it. From a business perspective, it is a lot easier to justify an expense than you already have than to try and add an additional one.
Number 3: rewriting existing apps (the guy who used to do my job suuuuccccckkkked).
Definitely seeing a downturn in large scale or new projects in general though, which is kind of the programming equivalent of saving not spending. Actually it's the literal equivalent of that, which is a problem for getting out of a recession.
Good question. I am at present working with project that has good customers and a decent revenue. So, the economic downturn did not affect much.
My suggestion is if there is a choice between choosing enhancing the existing projects or new projects, its better to go for the revenue generating existing projects. And investment in R&D projects may be reduced.
I believe "supporting" and bug-fixing on existing projects would not bring your much challenge and consequently experience. It can be a huge time waste for the career.
I am working on porting an existing business application to a new platform, which combines some of the aspects of work on an existing app, and some new stuff.
Its new because everything is going from Windows Forms to ASP.NET AJAX, and there are several changes involved in that process when it comes to the GUI and event based side of things, but its also partially work with existing stuff because the business rules are the same, the database is the same, although we have been gradually making improvements as needed to those.
On the other hand the company I work for supplies grocery stores which have been affected positively by more people eating at home, so despite being in Michigan, things are going well for the company, and we can afford to move this app onto the intranet.
The nice part about doing this is I get to learn all the new platform stuff, but we don't have to go out and get user input for some new set of use cases, plus we can work with the input we've received from the WinForms version.
I'm rewriting our existing applications. The fundamental design of the original applications wasn't flexible enough to handle our new business needs. Combined with questionable coding practices (a lack of separation of model, view and control and aging technologies with a lot of "NIH" syndrome) it was decided that rewriting the non-central portions of our applications was best.
Sadly, I'm not entirely sure I'm 100% qualified for this, but, I seem to be the most qualified of our team.
90% of my job is maintenance, or seems to be. But surprisingly, I've got about four projects of new development going or in the pipeline.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When you first fire up Visual Studio, or even before that (Hopefully)
What do you consider best practices when starting a new project?
Different things I have done in the past
Consider the technology choices
Attempt to identify the potential bottlenecks/brickwalls
Throw away the specification
Ask lots and lots of questions
Launched straight into code! (who hasn't?)
As programmers we should be methodical in our approach.
What do you do when starting a new project?
Start using version control right away.
It is always frustrating building prototype "throwaway code" that eventually gets thrown away - and then realizing that some of that code would be really really useful to have.
(If applicable) Figure out whether you are building a throwaway prototype, an expandable prototype, or a final production system.
I think that a major problem with a lot of projects is that people don't get this one figured out to begin with. They either over-engineer and the project doesn't deliver on time, or they write throwaway code that later becomes too expensive to throw away.
I do the following when building for others. WHen I build myself using more agile dev concepts, I still cycle through these steps. It makes it very easy to involve others as well.
Analyze: What do we need to do and why. Aka feature spec.
Design: what are we going to build, how will it work, and why? aka. Technical Spec.
Plan: What and who do we need, when, to do what
Implement: Build, test, repeat.
Launch: Almost there.
Support/Document/Train, etc: In case you get hit by a bus, or someone arranges for it.
Scrum
++
Requirements Gathering
Scope
Out of Scope
Pick Platform to deliver on and appropriate Development Environment
Calculate Expenses, Make budget
Schedule
Review at each stage and educate the end user of what is being made throughout
easy tips
Create my first test project.
One main thing I always like to know is, who exactly is doing what! even from the starting point. Stops alot of time being lost.