|
I am in the planning stages of a web app that will most likely be PHP. Aside from the recent discussion frameworks, I have a general question for you experimented developers. This one really is language agnostic. Before you put your thoughts to code, how do you document and plan your projects? I will likely be hiring developers to help as things progress and want to be sure that there is clear communication and documentation of what needs to be done and how the web app will work. I can visualize it all in my head but wondered if there is a better way than putting notes to paper. Tell me how your company does it, or how you as a freelance developer plans a project before typing a byte of code. I really want to be able to share what I see in my head with others that will be involved in this project but I am not sure the best way to do that.
|
| # ? May 8, 2013 21:29 |
|
|
|
| # ? May 19, 2013 00:08 |
|
|
mooky posted:Amazing!!! This is most helpful! Doctrine isn't a "thing" to learn strictly. An ORM is just a method of querying the database that hews a bit closer to the MVC pattern. Usually a framework that implements an ORM have dead easy configuration and obfuscates the DB connections and input sanitizing so you can keep your code as concise as possible. Adding an abstraction layer on top of database commands lets the framework handle the database connections intelligently. Usually that means you can swap in different DBs without any headaches. There are limitations with every ORM implementation, but on the whole they're much better than the alternative, especially if you're conforming to the MVC pattern. Edit: regardless, if you want to be a better web developer you should probably understand how the ActiveRecord pattern works. That's the basic foundation for most ORMs. Blinkz0rz fucked around with this message at May 8, 2013 around 22:16 |
| # ? May 8, 2013 22:06 |
|
|
DarkLotus posted:I am in the planning stages of a web app that will most likely be PHP. Aside from the recent discussion frameworks, I have a general question for you experimented developers. This one really is language agnostic. Varies for every project. Some projects I will do a comic-book style storyboard on paper if UX matters. I almost always have a text-only spec doc for each big project that covers; technologies, architecture, interfaces, required dependencies, application flow, etc. I keep the doc updated throughout the project. README file should contain the exact steps needed to take the project from clone to running and make sure you in some way keep a functional base DB schema committed even on top of whatever migration tech you use. A new dev should be able to check out your repo, follow the exact steps in your README to the letter (however complicated they may be), and be ready to contribute code right away. Keep a spec doc that is up to date and make sure to document things from the perspective of someone who has never seen the app before. You'll even find yourself reading the docs and thanking yourself in the future. Build modular code. I know this is a no-brainer, but keep it at the top of your priorities at all times. I'm completely rebuilding the data model of a big app at work right now and though the original guys did a lot of fast shortcuts and hardcoding data, they did it in a way that exposes interfaces and functions to the core functionality so I'm able to go in and plug in new functions to replace the existing backend code. The end user would never notice a difference, even though the app has been nearly entirely rebuilt. When you know you're doing something hacky, recognize it and encapsulate it in a way that you can plug in smarter functionality in the future.
|
| # ? May 8, 2013 22:33 |
|
|
revmoo posted:Varies for every project. Some projects I will do a comic-book style storyboard on paper if UX matters. I almost always have a text-only spec doc for each big project that covers; technologies, architecture, interfaces, required dependencies, application flow, etc. I keep the doc updated throughout the project. README file should contain the exact steps needed to take the project from clone to running and make sure you in some way keep a functional base DB schema committed even on top of whatever migration tech you use. A new dev should be able to check out your repo, follow the exact steps in your README to the letter (however complicated they may be), and be ready to contribute code right away. Keep a spec doc that is up to date and make sure to document things from the perspective of someone who has never seen the app before. You'll even find yourself reading the docs and thanking yourself in the future. Good points, that's very helpful information. I've never done that type of documentation before so I'm really looking for some examples which I haven't had any luck finding on Google... Can you help me out in that area or point me to some useful resources? What if you dream up a new idea tonight and want to document it so you can build on the idea and start to plan the implementation, where would you start?
|
| # ? May 8, 2013 22:46 |
|
|
What is the saying? Perfection is the killer of good enough? It doesn't matter what kind of documentation style you use, it's important that you get down the important parts and how they work together. I don't have a spec handy since I'm at home, but the gist is; anything is better than nothing. Document how your software is supposed to fit into its environment and you'll usually find that you have everything you need. A lot of my specs look completely different because it's just dumping facts and ideas into a Word document. Record what is useful for you. I will usually write out a feature in the spec with a lot of details, which helps my thought process. I will then build out a feature, referencing the spec for things like function names, table names, array schemas, etc until I'm done. Then I go back and tidy up the docs for that feature keeping the stuff that really matters. It helps if you use a branching development methodology because each feature and discrete component is built and merged into the project separately. If you dream up an idea tonight, sit down with a pad and pen and storyboard each discrete 'page' of interaction with the end user. Generally successful modern web apps have a specific flow that the user follows to accomplish a task. You might not know how a password reset page will look but you know that you'll need to accept (at least) an email address as input. So draw that out. Flowchart each unique path that a user can take to interact with your site. Then you can refer back to these sketches as a rudimentary checklist when writing out the spec (or banging out the code).
|
| # ? May 8, 2013 23:07 |
|
|
mooky posted:Amazing!!! This is most helpful! Because once you understand ORMs they make life amazingly easy, because they basically abstract away the gritty details of databases into something more akin to having persistant objects that can be queried as a database. More to the point, you can *extend* the objects and fit behaviors to them to facilitate an approach to OO more about *modelling* behavior rather than simply grinding over instructions procedural style. I have a tendency to architect my code , starting with UML and moving stepwise towards a final product. Not very agile, but I'm a greybeard, I earned that right. You think in terms of entities and how they behave. Rather than just a "members" table, which you hit with SQL and then do stuff to it, you instead have "members" objects with properties and methods that are specific to that object. So rather than authenticate($member,$username,$password) you have member=>authenticate($username,$password);. It might seem to be splitting hairs, but its conceptually very powerful and is easier to reason about at a higher level than just code. That said, ADODB has an ActiveRecord implementation in it, thats surprisingly useful, if not a bit simple (Pro-tip: Just wrap your more complex stuff in Mysql views and treat them as tables). I dont really get why ADODB doesnt get more love then it does. duck monster fucked around with this message at May 9, 2013 around 01:30 |
| # ? May 9, 2013 01:23 |
|
|
revmoo posted:What is the saying? Perfection is the killer of good enough? It doesn't matter what kind of documentation style you use, it's important that you get down the important parts and how they work together. I don't have a spec handy since I'm at home, but the gist is; anything is better than nothing. Document how your software is supposed to fit into its environment and you'll usually find that you have everything you need. A lot of my specs look completely different because it's just dumping facts and ideas into a Word document. Record what is useful for you. I will usually write out a feature in the spec with a lot of details, which helps my thought process. I will then build out a feature, referencing the spec for things like function names, table names, array schemas, etc until I'm done. Then I go back and tidy up the docs for that feature keeping the stuff that really matters. It helps if you use a branching development methodology because each feature and discrete component is built and merged into the project separately. Thanks again for taking them time to answer my questions. Everyone Else: Does anyone else do anything different, or is this pretty common practice?
|
| # ? May 9, 2013 13:20 |
|
|
There's really no standard one right way of doing specs. It all depends on team sizes, client needs, type of project, presence of quality control departments, and so on. There needs to be -some- specifications documentation, at the very least. I make mine a big hierarchical list of the app's actions/functions/modules, with screenshots/wireframes/mockups, as many as possible. It seriously helps when the time comes for QA testing.
|
| # ? May 9, 2013 15:57 |
|
|
Are there any php lint tools that can reliably detect uninitiated variables? I'm trying to refactor some terrible code that is dependent on magical lala register globals (yeah, I know man, I know... I inhereted this mess, I didnt write it) and due to the sheer size of the code I need something to lint various files with to find these uninitiated variable horror shows. Any suggestions? edit: Trying to convince the boss of the need for a rewrite, I showed him the DJANGO code for a rent management system I just use to track me and my flatmates rent, that fits in under a page of code + model + template, and man you should have seen the dude. Gears grinding hard in his head as I said "This line verifys the form. This line saves the form. This line creates a new form". He was actually almost in disbelief..... Going to stick with a php one, but I think he's coming around, because the sight of a mid-moderate complexity web app in a page of code with validation, ajax and all the fruit kind of blew his mind especially after I explained theres probably a 1000+ lines of code required to rewrite it in the long-drop (code starts at top, proceeds to bottom, then the coder hangs himself in despair) style of mingled html, php and sql vs about 100 lines, including the models and 50 lines of dreamweaver generated template. duck monster fucked around with this message at May 10, 2013 around 08:49 |
| # ? May 10, 2013 02:11 |
|
|
Well, Eclipse, Netbeans, and all the major decent IDEs will detect uninitialized variables in a file. In your horrible, horrible case, you might want to write some shellscript to concatenate all the files together into a monstrosity, then open that up in your IDE of choice and run a validation on it. It will probably find thousands of errors and light up the file all red and yellow like a christmas tree though. Also, man I pity you.
|
| # ? May 10, 2013 23:35 |
|
|
Well I'm liking Symfony2 so far, but gently caress me does doctrine have the whiff of over-engineering to it. I'm tempted to put it in the "optional" category and drag in an ORM that isn't written by insane java victims.
|
| # ? May 11, 2013 11:37 |
|
|
duck monster posted:Well I'm liking Symfony2 so far, but gently caress me does doctrine have the whiff of over-engineering to it. I thought that's what Symfony2 was all about.  Seriously though isn't it influenced by Spring?
|
| # ? May 11, 2013 14:00 |
|
|
duck monster posted:Well I'm liking Symfony2 so far, but gently caress me does doctrine have the whiff of over-engineering to it. I've been using Symfony2 for 2 and a half years now, and Symfony 1.4 before that... I don't think Doctrine is over-engineered at all. I used Propel, too, and prefer Doctrine. Some people speak against ORMs, but I think they're neat. I usually work in huge multi-year multi-team projects with dozens of business entities and complex associations between them, though. If your projects all have 2-5 business entities or something like that, then yeah, you might want to look into Silex (sans Doctrine) or Yii or whatever.
|
| # ? May 11, 2013 16:07 |
|
|
Pochoclo posted:I've been using Symfony2 for 2 and a half years now, and Symfony 1.4 before that... I don't think Doctrine is over-engineered at all. I used Propel, too, and prefer Doctrine. The more I read, the more I think your right, however what it *IS* is poorly documented. I still cant work out how to get the doctrine command to stop bitching about some undefined variable, and whenver I google it, its either worthless stackoverflow "This means its not configured right" or not stackoverfow "This means its not configured right. Ok, well that was already clear but htf do I configure it right! Google that "CLOSED: NOT CONSTRUCTIVE" I might pass on it as I need something dead simple that I can explain to the boss and not spend weeks bashing my head around a minimalistic poorly written manual. To be honest, I'd rather just stick with easy old activeRecord than a complicated mapping ORM... unless that mapping ORM was django, but thats been taken off the table by my boss who insists we use PHP. Yii I'll pass on. Too clownshoes for my liking. I'm actually finding laraval really nice, though I'm not yet sure if I can get it to generate me an initial schema from the stupidly huge database the existing app uses that I can then push around with model driven migrations. But blam, 2 pages into the tute and I "get" this one.
|
| # ? May 13, 2013 00:16 |
|
|
Doctrine is over-engineered because that's what you need to do in order to actually achieve unit testing. Doing things correctly always creates overhead. It's just a data mapper. There are more lightweight alternatives in that realm, though few that are actually updated. Data mappers beat the hell out of ActiveRecord, by the way...
|
| # ? May 13, 2013 01:55 |
|
|
McGlockenshire posted:There are more lightweight alternatives in that realm, though few that are actually updated. Hey I like that one.. One line per field, much better. quote:Data mappers beat the hell out of ActiveRecord, by the way... Ehhh....... The question is "What does this do to my productivity", and anything that involves lots and lots of loving around with xml files and associated horseshit seems to violate what I consider a rock solid rule of development: Throwing hardware at problems is always cheaper than throwing labor at it. That said, given a choice between Djangos data-mapper and RoR's active record, I'll pick djangos one any day. The question is, whats its PHP equivilent. duck monster fucked around with this message at May 13, 2013 around 12:14 |
| # ? May 13, 2013 11:00 |
|
|
Anyone here familiar with Zen Cart? My employer isn't really a web dev studio but for some reason we agreed to this project to set up a cart for this customer's site. They already have a log in else where on their site and if they're logged in there, they don't want to have to log in to the ZC cart because they get an extra discount... No idea where this code happens so I can check for an existing cookie though 
|
| # ? May 14, 2013 18:39 |
|
|
Looks like we'll be going with Laravel. Seems to hit that sweet point between lots of features and easy learning curve. I'm not totally sold on eloquent, as it seems to have the opposite problem of doctrine, its a bit *too* simple (I'd like *some* sort of mapping facility!) , but it'll do the job for now.
|
| # ? May 14, 2013 23:18 |
|
|
duck monster posted:Looks like we'll be going with Laravel. Seems to hit that sweet point between lots of features and easy learning curve. What exactly is a mapping facility?
|
| # ? May 14, 2013 23:26 |
|
|
Winter is Cuming posted:What exactly is a mapping facility? The db has a number of fields with German names and it'd be nice to have the benutzername field appear on the model as username. I guess I can always cheat with a MySQL view
|
| # ? May 15, 2013 00:41 |
|
|
duck monster posted:The db has a number of fields with German names and it'd be nice to have the benutzername field appear on the model as username. Yeah, okay, this has been on my wishlist as well.
|
| # ? May 15, 2013 01:43 |
|
|
duck monster posted:The db has a number of fields with German names and it'd be nice to have the benutzername field appear on the model as username. Would custom accessors solve that problem?
|
| # ? May 15, 2013 01:57 |
|
|
Depressing Box posted:Would custom accessors solve that problem? Welp, Laravel 4 is something I'm gonna be considering switching to, now.
|
| # ? May 15, 2013 02:50 |
|
|
I say go for it. The beta has been better than Laravel 3 stable for a few months now, and 4.0 stable is set to release by the end of the month.
|
| # ? May 15, 2013 03:05 |
|
|
I hope the Paypal bundle fork I did to utilize the Adaptive API still will work.
|
| # ? May 15, 2013 03:11 |
|
|
|
| # ? May 19, 2013 00:08 |
|
|
Yeah Laravel is pretty neat. Right now I pretty much choose Silex -> Laravel -> Symfony2 for projects in order of complexity. I've done so much Symfony though that I ended up being a moderator in the official forums, so all my projects must have been huge. Not always though. I've done nodejs once or twice. Cloud9 is pretty neat for nodejs devving.
|
| # ? May 17, 2013 00:47 |
|
