Thinking out loud on topics
Stuart Herbert
I hope this export works :)
I've been kicking around ideas for what might qualify as PHP fundamentals, and putting them together into a mind-map. Hopefully the map is attached, and should be viewable in FreeMind 0.9. It is far from complete, and I'm sure that some of the topics need to be dropped, but as it's gone a bit quiet on the list I thought I'd share and invite feedback :)
Best regards,
Stu
Rob Allen
I'm generally in agreement with your mind-map.
Some thoughts, in no particular order, and not particularly well written:
We need to decided on our target audience. i.e. are we talking about single devs, small teams or are we talking google/facebook sized orgs? Does the type of work they do affect things? e.g. those working directly for a paying client are in a different situation to those working for a bank or a university.
In terms of tools and practices, I can see a system where we have the article teaching the practice that then links off to separate articles showing implementation of the practice using a given tool. So you could imagine an "implementation" article for each tool which in some ways would mirror the way you can have a design pattern described but then implemented specifically slightly differently due to the nature of the problem being solved. In the same way, the best practice (e.g. database versioning) may be implemented differently with dbDeploy compared to LiquiBase.
I've already mentioned that I would like a policy that out of date/wrong articles are removed rather than left to rot if we can't find someone to update them.
In general, I don't think that a wiki is structured enough by default and would require overhead by us to keep it sane. I also think that the meta data tends to get in the way of the articles in a teaching context. I have no knowledge of Moodle so can't comment on it. I like the idea of "programmes" of content with dependencies though, so maybe an e-learning base would be best.
I would prefer not to have comments as it distracts from the material. We will need clear feedback mechanisms and I could see using either the current wiki as a discussion area to handle feedback on each article or a bug-tracker. Whatever we use, having the discussion in public and timestamped is handy in order to provide some credibility.
Organising the material into groups is something we'll need to do soon. Your mind map items 2->5 are a good starting point I think.
For any given group of topics, we'll probably have basic and advanced material. We need to decide if we organise by level first or topic first. e.g. do we put basic deployment and basic vcs together or do we put basic deployment next to advanced deployment? A curriculum implies that we would do 101 topics first and then 201. I think I like this approach
I agree what less is more. We need to ensure that we have a phased approach and can then keep track of good ideas that we are not ready for. For example, I wouldn't exclude teaching of PHP/JS/Whatever forever. However, it's very clearly something to be looked at much further down the line, after we have the practices curriculum done.
That's all that comes to mind in this brain-dump. Let's continue the conversation and try to come to decisions by the end of the month.
Regards,
Rob...
Stuart Herbert
Thanks for the feedback :)
On 19 Jun 2010, at 12:47, Rob Allen <r...@akrabat.com> wrote:
> We need to decided on our target audience. i.e. are we talking about single devs, small teams or are we talking google/facebook sized orgs? Does the type of work they do affect things? e.g. those working directly for a paying client are in a different situation to those working for a bank or a university.
My feeling is that our target audience should be the single devs and small teams. I think that the vast majority of blogs out there (especially from the larger names in our community) already cater for the larger teams and organisations. Plus, the vast majority of PHP developers will never ever ever work for anything the size of Google and Yahoo, and therefore need different advice to assist them.
I'm sorry, but I do cringe whenever I see well-meaning folks offer the standard "throw more hardware" at a problem, because they work in a world where they have server farms, dictated suites and dedicated data centres. That's just a completely different world to the one that 90-odd percent of developers work in, and I think that world is already well-covered.
What does everyone else think?
> In terms of tools and practices, I can see a system where we have the article teaching the practice that then links off to separate articles showing implementation of the practice using a given tool.
+1
> I've already mentioned that I would like a policy that out of date/wrong articles are removed rather than left to rot if we can't find someone to update them.
+1
> In general, I don't think that a wiki is structured enough by default and would require overhead by us to keep it sane. I also think that the meta data tends to get in the way of the articles in a teaching context. I have no knowledge of Moodle so can't comment on it. I like the idea of "programmes" of content with dependencies though, so maybe an e-learning base would be best.
I could see the wiki storing the "tools library" for lack of a better name for it. I currently feel that such a library would be helpful to people, and help us keep the practices as tool-neutral as possible.
> I would prefer not to have comments as it distracts from the material.
Mmm ... I think one of the strengths of the PHP manual is that it has been annotated by it's readers. Perhaps we should allow comments on the tools library (if we create such a resource) but not on the practices?
> We will need clear feedback mechanisms and I could see using either the current wiki as a discussion area to handle feedback on each article or a bug-tracker. Whatever we use, having the discussion in public and timestamped is handy in order to provide some credibility.
+1
> Organising the material into groups is something we'll need to do soon. Your mind map items 2->5 are a good starting point I think.
I'm hoping someone can improve on the structures that I've suggested :)
> For any given group of topics, we'll probably have basic and advanced material. We need to decide if we organise by level first or topic first. e.g. do we put basic deployment and basic vcs together or do we put basic deployment next to advanced deployment? A curriculum implies that we would do 101 topics first and then 201. I think I like this approach
I've been listening to my guys in the office and the questions they've been asking over the last few weeks ... and it made me realise that a flexible approach might have the widest appeal. I'm wondering whether a points-system for the curriculum (like how modern degrees are done, where you can pick your modules from a list and get points totted up as you pass each module) would be a god way to go. We could then give each person their personal page (to share with employers etc) with their attainments to date.
It's just a thought, and one that definitely needs a lot more exploration.
> I agree what less is more. We need to ensure that we have a phased approach and can then keep track of good ideas that we are not ready for. For example, I wouldn't exclude teaching of PHP/JS/Whatever forever. However, it's very clearly something to be looked at much further down the line, after we have the practices curriculum done.
I've been struggling to figure out where I feel the line should be drawn on this one. I'm currently feeling that it falls somewhere between teaching the language and teaching how to use the language. An example of this from this week is the use/abuse of global variables in code. I feel we need to consider teaching people how to make their code modular (use a framework or make your own code into one, so to speak) but I'm not sure about teaching actual language syntax at all.
> That's all that comes to mind in this brain-dump. Let's continue the conversation and try to come to decisions by the end of the month.
Next Saturday should provide the perfect opportunity for that :)
Best regards,
Stu
--
>