Laravel Project Organization - laravel-5

i have been learning laravel and truly its quite fun. but so far the projects i have been doing are just small applications with very few controller files and model. Not much to "Organize" per se. But my question is,
1# how to organize files when a project gets larger and larger?
2#is there any recommended project structure that i could follow from the start of any project so that even if in future the project grows bigger, things are modular and easy to manage with?
thanks.

Welcome to Laravel world :).
The first thing that I have to talk to you before other people: StackOverflow isn't a place for asking opinions. It's should be treated as a technical forum, and questions that you want to ask should be something that won't be leading to a discussion or different opinions from different users (check here "We prefer questions which can be answered, not just discussed", discuss). Simple rule of thumb (I might be wrong but it's my opinion about what StackOverflow is): You ask a question and you should only expect one good answer (That's why we have a "Check if question is solved" feature).
Moving forward from there, I'll answer your question:
There won't be a good answer to your question. Just like what Jeffrey Way said in one of his Laracon speech: "We don't know shit either".
We have a lot of conventions here and there, a lot of rule, but nothing is "right". Every convention has flaws, it's just that some of them are a lot better than rest of the others. So, keep learning.
There are some absolute "Must-have" skills, though, like learning Object Oriented Programming, using Composer. Learn that because it's absolute needs for a PHP programmer.
Making a scalable project is about an experience. The best answer is that you have to face one, either by finding an internship, a junior web development career, being a volunteer to a Laravel project, etc. But another answer is to learn, search "expert answer" about how to build one on Google (like https://www.sitepoint.com/horizontal-scaling-php-apps/), ask Quora. You will find lots of answers because again "We don't know shit either".
Lots of companies have a different system that others don't use. They'll use what they feel fits theirs needs. For your indie project, you'll just have to keep learning and breaking things until you'll find the one. For other companies, you'll find them knowing what they want to do and you have to do everything their way about how to make a scalable project.
Experience, learn and learn, that's the answer.

Related

Refactoring Practice/Workbook

I recently saw the Refactoring Workbook while I was cruising Amazon the other day. I haven't actually gotten to read it yet, but it presents an interesting idea. The most enticing part of a "workbook" is that we can finally have every day practice for dealing with tough problems in a systematic way.
Onto the question. Does such a resource exist online or in other books? I know someone is going to suggest Open Source, but some of those projects require understanding of a huge context. I'm looking for something I can pick up, read a few pages, and refactor. Consistently.
As a side note, if such a resource doesn't exist online - it'd be a gold mine of an idea.
Industrial Logic has e-learning resources that I think are somewhat like this.
They aren't free, and I haven't seen enough of them to vouch for the quality, but I know some of the people involved in creating these materials and would expect they're good.

Should a developer be a designer?

I have been developing websites for quite some time and I am not so good in designing websites? My Boss is refering me to take some lessons on it.
But I really want to stick to development rather than designing?
You don't need to be a designer. But I would highly recommend you understand the process and some of the techniques used. Having that knowledge will assist in both working with designers and providing better back ends.
I'd do the course, but make it clear to my boss that it's not what I want to do as a main job.
Answer yourself these questions:
What is your objective, the dream? developer or designer?
What are you best with?
Will I be able to justify with my design requirements?
It this common that a developer should be a designer too?
Will you be able to to concentrate on both, the ever changing trends and techs.
Having said that, I have seen such people having both skills but still they don't weigh equal in both parts.
Developer as well as designer:
Chris Coyier of css-tricks.com
Pekka
It depends on what you want to be in the future. Actually, designing and programming are two different skills. Obviously, for websites two things are both required. As a developer, if you have some basic knowledge about design, it would help you and also the designer to make the website much easier to maintain. But personally, I do not thinking you have to dive into design.
a good developer knows a lot about design, but dont have to be good at designing something.
i've seen to many developers building up a given design and making so much mistakes, because they don't see the little intricacies that are enormously important for a well designed website.
One particular design aspect I find many developers (good ones) are not necessarily extremely strong at is understanding of colors harmony. Even though it seems like easy thing to do, find the right combination of colors on a page, it is not always that easy. That course may be helpful in that regard.
I started of as a developer and then progressed into being a Developer/Designer.
You start to understand design aspects, UX aspects and the likes.
So i believe a good developer should also have a good understanding of design aspects as well
The bottom line is your boss thinks you'd benefit from a bit of immersion in design, and you probably will.
It doesn't sound like he wants you to become a designer, just get a feel for it. He's not asking for a career change.
There's always benefits in learning something new. And if your boss is backing you taking some time to do it got for it.
As a developer you should know something about usability and software ergonomics. You should know the basic structure of a website. And you should be able to implement a given design.
I think it is not the job of a developer to create a design.
Try to answer: "Why does your boss want you to improve skills in design? "
Your team is too expensive and boss is going to fire designer. He is wondering is it possible.
Your designer complains to boss that developers constantly ask him to refactor insignificant details interrupting from common tasks. So your boss wants to delegate small design decision to developers.
If it's so, I think nothing is a bad to improve design skills if your boss doesn't want you to convert to designer.
I also agree with all those people, who state: Developer and designer are two different roles.
Well, if developing is the field you are comfortable with, stick with it.
But learning is never bad. Try to gain knowledge first, after taking the classes, you can answer this question yourself
Wow, I'm actually in the exact opposite of your situation. I'm a designer just crossing the line of web development. But in my case, it was my own decision and it wasn't imposed by anyone.
It's always a plus if you have web development skills on top of design skills. I guess it holds true if you're a web developer and have design skills as well.
It never hurts to learn the basic, like others have mentioned, but keep in mind to stick on what you're good at and master it. Its better to be a master of something rather than being a jack of all trades. With so much competition out there, you really have to excel at your craft.
Learn both, but master one, I'd say. I personally see myself as a developer foremost, but I do know a thing or two about design - and, more specifically, implementing it (think CSS and the like).
However, I gratuitously admit that I am not good at making a design that looks good. A functional one, maybe, but not good. You could say something like that to your boss - that yes, you are capable of learning to design, however that you will never be as good as a real designer. Likewise, a designer learning to program will never be as good as a dedicated developer.

Keeping abreast with technology

I know this is not a technical question, but this is something I believe could be best answered by the technology community. I've been in software development for ~2 years now, but most of the time, it has been a learn as is needed experience. I was recently asked by a friend on how to go about getting a strong foothold on technology so as to be able to easily adapt to new technology that comes up every day.
I'm not sure how to answer his question as my way of approaching this situation has been learn as you need. How would you suggest someone proceed if they were getting into Microsoft technologies today? Where would they start, and how would they proceed? To be able to expand their knowledge to the new advances we see everyday (linq, silverlight, entity framework, mvc framework and the ever expanding list).
Basically I think my question is a mix of both "how to be a better programmer" and how to get to the "next level" in technology (where you are no longer an intermediate programmer, but able to see the whole picture and easily assimilate new technology)
Thanks in advance.
One thing I enjoy is to listen to technology podcasts while I commute, exercise or do household work. You will net become an expert alone by listening to podcasts, but you will get a lot of input. In particular I enjoy .NET Rocks! but Stack Overflow also has a podcast to name a few.
Read, do and try new things. Do that for a few years you'll eventually end up an experienced programmer.
I think this post by the Misfit Geek could help you out a bit. I think it gives some great tips and gives some good advice on how a respected technologist has stayed up on technology.
How did you learn what you know
Hope these help. I also agree that podcast are a great source of info, at least to point you to the best new technologies. I listen to .Net Rocks, Hanselminutes, HerdingCode, and DeepFriedBytes just to name a few. I also follow some good .net releated blogs such as CodeBetter, Devlicio.us, and Los Techies.
Good luck!
I spend at least 1 hour a day just reading blogs, and listening to podcasts. You cant possibly get involved in everything new that comes along, but having knowledge of what's new is just as important as trying new things out.
If you want to specialise in one thing, then that's fine, but always try to include new technologies into your projects, and look for better solutions to things you have done in the past.
You need to follow what the technical community is interested in. Blogs are the best way that I've found to do this. Pick at least 50 that cover a wide range of topics, and you'll know what is coming down the pipe.
Keep involved in podcasts and blogs. Set aside at least 15 minutes a day to ready them or listen to them. Take their ideas, find which ones apply to you or are interested and add it to your personal development plan to learn them.
Here are a few previous posts regarding these:
Podcasts
OR
c# blogs
Interesting project + new technology = motivated learning.
There is no alternative to getting your hands dirty. Take one of the ideas you've had rolling around in your head and implement it using buzzword technologies. Be prepared to realize many hyped technologies are mostly just hype. Hopefully you will find some real gems, change your perceptions of what is possible, and add some tools to your toolbox all while achieving a goal.
Here's the list of Top 200 blogs for software developers. Try to read some of them and subscribe to what you like or find useful.
Blogs are great for spotting trends and finding some advice about the newest technologies, but if you want to learn something in-depth, you need books. Try to read 3 or 4 every year.
Finally, local user groups. Find and meet your fellow developers face-to-face and find out what they're doing and what's on their minds.
Attend meetings of local user groups.

Project Termination [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
I was recently working with a team to develop an online system. We had worked for several months and were making good progress when the project got canned. We all felt strongly that the projects completion was important and that it would have great outcomes on our consumers productivity. After being frustrated for a while I thought I should ask some people with more experience.
What is the best way to deal with the frustration of a canned project and move forward so that it doesn't hold future possibilities back?
On a well designed project, some of the code you developed can be reused in future projects, making it worthwhile. Even if you can't use any of it however, you and your team probably gained valuable experience that will help in the future as well. Think of it as an expensive team exercise.
Don't put your heart and soul into someone else's project?
I do a lot of work for different people and while some projects are more interesting than others they're not my projects so I wouldn't be too broken up if they got canned. I've got my own stuff I'm working on. No one can terminate those projects but me.
Grieve. Such a loss will produce a grief reaction. Not one as strong as though you had lost a loved one, but it's a grief reaction nonetheless, complete with all those stages of grief.
Failure is the best (and sometimes only) way to learn new things, even if the failure is not your fault. There are many different angles by which you can salvage useful information from this:
Code that is reusable
New technologies or skills garnered from the project
Lessons about project management based on how the failure was handled (maybe the project should have been canceled much sooner, before the team bought into it)
Non-technical ideas that you can reuse in other projects for the company or even in your own endeavors.
I highly recommend doing a postmortem, but don't dwell. Most projects get canned at some point in their cycle and if you let it affect your morale, it becomes a downward spiral from which it's hard to recover. You may become oversensitive to even slight requirements changes.
Attack every project as though it were your own. By this I don't mean invest all of your emotions (as stated here already by Spencer Ruport). But write all your code and organize all your code in a manner that you can easily pull out tools that you might need in the future. You never know if you will need it...but odds are you will. If you write an account manager app...do it in a modular reuseable fashion. If you write an image uploader...write it in a way that it can be ported to any other project you have. Write helper functions around all of your major features to make it more user friendly down the road.
This of course requires some planning prior to losing the gig! No worries. It rarely is because of you that you (the whole team) loses the gig. Some financial decision or business decision is usually at play. In this case most likely the economy is what killed you. In the case that you don't have any physical benefits to the failed project...look at it as a learning experience. Inevitably...no matter how good you are...you probably had something that you did that you don't or no longer agree with. Learn from that. You most likely also did something very cool that you loved. BLOG ABOUT IT! This serves two purposes..you just created something tangible from the project...and you put it somewhere that you won't forget about it.
Sucks all the way around. But at least there is a great market out there right now! Contact me directly if you want my headhunter list (80 technical recruiters in CA and the US).
Two things:
Your Investment in the Project & Code: The fact your team had such strong feelings for the project & were so frustrated on it being canned is a good sign - it means you are a true developer/programmer and are not just doing a half-job for full-pay. So to deal with the project being canned: know you & your team are committed to your work & while that project may not have panned out, you guys sound like a real credit to that project & any other you may work on. It sounds like you just need to find a project/opportunity that has the legs.
My Experience: Projects get canned for all sorts of reasons - budget, lack of confidence from stakeholders, too late to market, changed scope etc. I would enquiry/investigate why your project was canned. If it is budget or lack of stakeholder confidence then it is really good news. It means an opportunity has just presented itself to you & your team. Consider pursuing it!
Either way your team will have grown from the experience: both technically & from a business perspective.
cash the paycheck - that always helps ;-)
ask if you can have the rights to the canned project, since they don't want it, then open-source or commercialize it yourself if you think it's worthy
it's good to care about your work; it's not so good to obsess over it.
there will be other projects even better than that one in the future; they might also get canned, for any number of reasons both rational and irrational
Good example: I once worked with a lady who spent 2 years on a document-imaging project that was canned a few days before it was supposed to go live; it was canned because the new manager did not like the old manager, and the project was his "pet". This lady's reaction: "I'm looking forward to learning something new!"
This can be used to bring your team closer together, if you have the right sort of people. There is nothing quite like working hard on something you believe in and then having it canned. It can depress, but it can also motivate people to want to prove next time that they can do the job, that they had the right idea.
It helps to galvanize the team; we were there, we worked hard, and it was taken from us.
Of course, it's better not to be in that situation to start with, but when you find yourself there use it to build the team.
Sunk cost cannot be used as a reason for the continuance of a project. If the leaders have made a business decision then I'm sure that it is well motivated, however upsetting.
I'd console yourself in that big swings should be celebrated in business, big companies do not win every bid and complete every project they start. So console yourself in having lost once, maybe you might be able to change the way things were done, or focus more on the project stakeholders as well to make sure they understand why your project is worth completing compared to the other projects and business initiatives at the company.
I'll finish with my favourite saying:
"Good judgement comes from experience. Experience comes from bad judgement."
Learn from it!
Watch a Rocky movie (the last one was good) and have a few beers. There's no way not to put yourself into a project, there's no way to not feel bad about a project being terminated or failing, there's no way not to feel negative about the company. What makes a good programmer better is taking all the emotions, anger, etc. and being able to release it and move on with the same focus and dedication that was there with the first project. All part of life and all part of working in IT.

Big projects - Road to Success [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 3 years ago.
Improve this question
I've been making small scale projects for a while now. I haven't started a large project, yet, because I haven't come across anything which I needed and wasn't already accomplished by some other FOSS. Until now. I want to make a program which will allow users to interactively learn secondary languages (I'm kind of want to make it as close to Rosetta Stone as I can).
Right now I'm the only developer since I'm not sure if I'm biting of more than I can chew and don't want to waste any contributors time.
So far I've been planning how the project is going to work and setting up tools to make the project start smoothly and for it to be readily accessible for when other users are ready to contribute to it. I've set up a SourceForge account, a git repository, as well as a document which lists all the features and what the program is going to accomplish.
A basic break down is that the suite is going to be written in java, and the suite will have the ability to support many languages via their locale. The courses for learning the languages will be written in jython. Course-makers will have the ability to use pre-made jython courses to teach their course, or make their own original ones. I'm hoping this will allow for the software to teach copious languages via many mother tongues.
I'm also planning on having a repository of "released courses" which are ones which I (or people who better comprehend the language) think are top-notch courses. This will hopefully make the program seem more professional and secure to the users while allowing third party participation.
With this in mind:
Are there any fatal flaws or suggestions about my project you would like to make?
Is there anything I'm missing about making a big project in general?
Thank you for your time and effort,
Joseph Pond
You will always be biting off more than you can chew if you don't believe other people should consider your project worth their time. This is much more of a leadership point than a programming point. But seriously, work it out: is this idea something that you believe can happen even knowing that you are currently unprepared for many of the challenges that you are about to face? You've given us a rough outline. You'll be giving others a more thorough explanation, and it will soon become obvious that you've overlooked some stuff. Nobody can keep that from happening to you. Having said that, if you think that you have a good grasp of the requirements of most of the components and you believe you can thoroughly describe the requirements to others with appropriate skills, I'd say go for it.
P.S. -- If you have any mock-ups, that would make it seem like a sweet deal from a prospective developer's perspective. It sounds like the selling point is the extensibility of easily designing new courses. If that's so, give an idea of the basic structure of the Jython. When my supervisor gives me a task that I understand thoroughly, I'd rather he didn't show me how to get started or what design or implementation to use. When I have no idea what he's talking about, the roughest of sketches gives me days of a head start.
Are you also the only analyst, translator, technical writer, and tester? This sounds like a large undertaking for one person. Do you have a deadline? In my opinion you will need at least another developer and tester. Even more if you have tight deadlines.
Just find the right person who really agrees with your idea and will take the ownership.
I had been involved in several projects but I dropped out some and only worked on the one I really interested in. So, look at it in the reverse side, looking for a contributor is not easy and must find the person has the things I mentioned about. Then, you can talk about keep contact,, system... project manage..etc. If you can't find the right person, even you have a good system, you are just wasting your time and going nowhere.
Okay, a couple things. First, it's better never to do a big project. Do lots of small projects instead. If it works out that what you get at the end is a big thing, that's good.
Second, a lot of times what works best for this of thing is to think about how you can make something to make it all easier. in this case, you have two issues: making something that does the various operations needed to display and give feedback (I'm working through a Rosetta Stone course myself, they're pretty cool.)
You're really thinking about a course authoring system; you can't write all the materials for all the languages, so you have to make it easy to do the authoring.
This sounds like a job for a DSL, a domain specific language.
And it sounds like a really cool idea.

Resources