Localization as an afterthought-- screwed? [closed] - php

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
So I signed on with a startup web development company as a subcontractor. They are putting together a large, complex user/product management system for a company that needs to support multiple levels of hierarchial localization. I signed a 3 month contract, and upon looking at their code, wish I hadn't.
They opted to write their own MVC framework (I guess the client company didn't want to use a prewritten one) and it's extremely poorly written. There's SQL scattered throughout almost every model view and controller (and there's no parameter-based find methods, it's all SQL) and they haven't even THOUGHT about localization yet-- something that will have an affect on nearly EVERY query.
The due date is 4 months away, and I honestly think we'd make good progress by scrapping the whole thing and going with CakePHP. Have any of you been in a similar situation, and what did you do?
PS: This is written in PHP/MySQL.

Rewriting from scratch is almost always the wrong idea (Read Joel's article Things You Should Never Do -- Part 1). But you have to start implementing small changes (big in your case). The sooner you get the code cleaned up the better it is for developing in... Get a sane data access layer and try to sort out the ad-hoc MVC first.
Also, while you are fighting battles, start planning out what needs to happen and get the upper brass used to the idea that some features might not make it in. I don't know your code base, or big or how messy it is... but if it is really bad then they should be prepared to ship a product minus some features rather than a half-baked solution.
Take charge on these issues, you (like the rest of us) get the pleasure of inheriting the sins of a codebase's previous owners. Is there any chance they would extend the contract or pay overtime for extra work you put in?

When you work for someone, you play by their rules. I've worked on a couple of sites using Expression Engine. I hated every minute of it, and I strongly recommend against it every time it comes up with my client, but what can you do, other than grind through the work until you're done?
Feel free to offer the suggestion about CakePHP, but I would drop it if nobody wants to hear it. Be happy you're only on for 3 months.

Related

Make PHP site, then implement Laravel or build on Laravel from the get go? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Should I:
A. make this medium to possibly huge website with PHP first and then
implement Laravel
or
B. Learn Laravel now and build the site with Laravel from the get go?
About the site I want to make:
Scalable - it can handle 200 or 200,000 users using the site at the
same time.
It will mostly run on text entries, calendar functions, lists, some
social networking within and outside the site
I want the customer to not experience lag.
I will most likely be the only person working on the coding.
Each user will not be able to upload pictures or videos at the
beginning of the project, but I would like to allow it as the site
grows to maybe 15-30MB/user.
Credit card processing or Paypal will be used as a recurring charge.
I'd like to start small and grow with the customer base
Due to cash flow Cash flow I'd like to use the least amount of $ possible in the beginning
I may pass it off to someone else in the future if it gets too big
too fast
About me:
After a lot of research it looks like Laravel is the PHP MVC
framework that will stand the test of time (5 years~ hopefully)
First time asking a question - this site has helped me so much over
the years!
Just learning PHP, Javascript, SASS, MySQL, etc, because I have an
idea and no money to hire someone else.
I do enjoy creating things though and have enjoyed HTML, CSS, and VBA
in the past.
If you in near future wanna implement the site with laravel I think you should do it now even if it delays you for 1/2 week to understand laravel clearly. Because as days go by your codebase grows larger and you'll neither have time nor will to convert it rather than adding new features :)
Jump right into Laravel if you are new to PHP
Install the Homestead virtual machine
Follow the entire Laravel From Scratch series
Do the Basic Task List app
Then explore some more of Laracasts and go from there.
Bonus:
Get PhpStorm
Use git version control
Get a GitHub account and store your code in a private repo ($7/mo)
Definitely start with Laravel. It will significantly improve your development time and make your code more maintainable. This is specially true if you are just starting with PHP.
Learning PHP first is also good, but if you are trying to create an application also i'd suggest learning Laravel First, this would improve your overall knowledge about how MVC frameworks work, and laravel's awesome features.
To learn laravel, check out this link: https://laracasts.com/series/laravel-5-fundamentals
Even if you want to use Laravel sound knowledge of PHP is a must. Laravel is based on MVC(Model View Controller) model. So it wont be that much difficult to handle as there are several tutorials on MVC. You get the PHP OOPS fundamentals and then jump to Laravel.

Learning process of PHP (Framework Symfony, OOP) [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 7 years ago.
Improve this question
I am starting a new challenge. I am on my way to learn PHP since (I already have good knowledge in HTML CSS), i would like to have you advise in a good procedure of learning this.
To be specific my final goal is to be a very developer in PHP by the end of 2015 and able to work on project on my own and/or with team as freelancer.
I would like to hear from you guys a step by step learning programs which will conduct me to have confirmed knowledge in PHP OOP and Framework Symphony2. As i don't want to skip the stages i'd like your advise :
I have basic understanding of (loop, if/else, function).
I am looking some course (updated) and exercise to push up my level slowly but efficiency. A list of step would be a great start.
I'd suggest that you ensure that have a solid understanding of generic programming principles before you focus on a specific language. Knowing markup languages like HTML is relatively easy in comparison. When you get to programming, there's a lot more things to consider.
There's plenty of available free resources that should be able to help you.
http://www.tutorialspoint.com/computer_programming/
welcome to SO. There are lots of resources out there, some easier than others for a beginner. I would start on something like code academy and augment that with resources like php.net.
Then when youve covered those tutorials (I would do all the markup stuff like HTML as well) think of a personal project and build it. Its all very well reading manuals and doing tutorials, but you need a real live project to force you into finding solutions for real debugging issues. That cant really be taught.
Its worth noting that PHP isnt the only server side language out there, so keep an open mind and be ready to investigate other avenues as you find them.
Bear in mind to be able to hold your own in the industry is very different from being able to handle your personal projects ok. There are a lot more variables (no pun intended) in industry and the skillset you need to have is often wider.
Good luck with it.

Procedural PHP vs Object Oriented PHP [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am fairly new to PHP (you just have to see some of my previous/recent posts!). I have done a lot of my learning by studying other people's frameworks and attempting to rewrite them for my own purpose.
Out of the examples of code I have seen, it seems about 50/50 Procedural to OOP. My question is not which is better, but when should I consider using OOP over Procedural?
By the way, I don't want to encourage an open discussion of personal opinions as to why one should be used above the other. I am fully aware, after researching, that some people just prefer to use one or the other. I am after a legitimate reason as to what would encourage me to use one over the other and in what situations.
I have also read through a few different (but similar) questions on the subject, but they seem to be flagged as not constructive because it starts a debate. I don't want this, I am on a Q&A site as I am looking for an answer, not an argument.
Even thou it is 2014, you are still allowed to wash your dishes by hand, communicate with all your friends only in person, landline phone calls or letters send by the local postal service.
And you might feel incredibly well doing so.
But if you try to host a lot of dinner parties for a lot of people and organise important projects with a lot of people from remote destinations, having hard deadlines, you might consider getting a modern dishwasching machine and a smartphone.
Same goes for OOP vs. procedual. If you are just adding a tiny piece of functionality (display the current date, echo a random hash string) on your wordpress weblog: Go procedual.
If you are writing a tiny tool that does something you need to get done, if you are writing a tiny cron job batch script in PHP or if you are just fooling arround - do as you like.
But if you plan to develop sustainable, maintainable, testable, reusable, quality software that has a lot of features you should at least use OOP. Because it is bloody 2014.
OOP will enable you to blackbox and whitebox test units of your code seperately. It will enable you to not only efficiently reuse libraries and modules written by others but alos enable you to produce modules and libraris that can be reused by others.

Should I add a disclaimer about known issues in my code in the documentation? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm writing the documentation for a WordPress theme project that I've been working on for a long time. The theme is usable and stable enough for release. I'm releasing it, plus its documentation and tutorials for free but am charging for support/customization. However, there are some issues with the code (optimization, mostly) that I've been unable to resolve after months of trying. While I've learned a lot about PHP while doing this project, I'm still a novice and I want people to know that I'm aware that my code has these specific issues, and that with support (via donations or them purchasing support from me), I might be able to hire someone in the future to fix these problems.
My question is, should I include a disclaimer that basically states what I just said above in the documentation? So that people are aware right from the start that while my product is usable and I'm confident in it, it still has these known issues that were beyond my skill level to fix? Non-coders would probably not notice the issues much, but more advanced people in the community may...
...or would it be best to not mention the known issues or my novice skill level at all, and wait to see if people bring them up?
We have a standard 'Known Issues' section in our release documentation. I'd say yes.
If you were going to invest money or time in a new acquisition, would you want to know about its limitations? Probably, so make that information available. You might lose one or two potential users who consider the known issues showstoppers, but they're people who would have got frustrated when they discovered the issues anyway.
Yes, it's always good to have a known issues section; if nothing else, to keep your inbox empty of the same emails complaining about the same bugs you already know about.
In my opinion, you should just list all of these issues/bugs and state that you are currently trying to fix them. You don't want to be bombarded with e-mails of issues you already know about.
would it be best to not mention the known issues or my novice skill level at all, and wait to see if people bring them up?
I can bet they will come up. Don't think that they will not come across these issues. Better to publish the known issues. It should have sections one is things to avoid and then if the user does that, what the user should do to come out of it. If I am paying for any software I would certainly like to know what are the limitations first.
Definitely Yes! A well-informed user is better than a frustrated one!
Treat your customer the way that you would want to be treated.

Drupal research strategy (custom or ready module) [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
When you get a description of some project that should be made with Drupal, and requires some extra-functionality (beyond core and most popular modules), how do you decide how're going to do it?
Do you spend a day or two (or week?) searching for all possible modules, narrowing down the list?
What is the cricial point to start writing own module?
What is the cricial point to start altering some more or less suitable module?
To be more precise, lets imagine I am going to do a time Booking system in Drupal 5, but there are no modules that do exactly what I want.
What are the most important pros and cons when it comes to selecting the ground to build the Drupal project upon?
I will use a pre-built module only if:
it is for UI purposes. For example, an image gallery.
it is really, really well consolideted (like the views module for example, or imagecache), is specialized in one task and does it well, and if it serves my purpose whithout any modification (because it just fits, because I can adapt the requirements to make them fit, or because it offers extension points like an api or such)
what I need to achieve is peripheral to the system, and there exists a module which will do something similar, and it is easy to modify it and then maintain it
I will make my own if:
the functionality is "core" to my system and there is not a module which fits
the modules I found are new, not actively maintained, messy coded, etc...
In fact I usually prefer coding my own modules, which I have total control over, than adopt foreing ones, with the risk of having more troubles with them than advantages...
I'd say it really depends on what it is you want to do. If what you want to do is not to complicated, and you can't find a module for it. Chances are that even if you do find one or one that is close, that you end up spending more time searching that would have spent making your own. Where that line is, depends on how skilled you are and how intimate you are with Drupal. After doing lots of small custom modules you end up with a lot of snippets you can reuse making writing new modules quite fast.
Sometimes you can even take a module and make your own to modify it, to make the origin fit your needs. For me, I usually never spend more than a few houres trying to find a module. If I can't find it by then, it's usually
Not maintained and way old.
Still in development
Even if you can get a bit of a head start you might end up struggling in the end, with bad database designs and the like. But it's hard to say where the breaking point of using others halfway there code is. It depends on how hard or how much time YOU have to spend, to make it, vs the struggles you get using it.

Categories