Wedge

It seems like some basic things I would expect aren't available, and I'm not sure a lot of the mod developers know what they're doing, to be honest (I'm know you guys are good though ;-)).  Plus, a release every year seems odd to me.

On the web side, my team uses Drupal and Rails, so I'm curious how much influence those frameworks had on Wedge.

- are you guys experienced enough with software development to build a robust and scalable platform?  For example, do you understand the internals of PHP, cacheing, etc.?

- will there be a utility to convert from SMF?

- do you have a big enough of a team to pound away at the the core, and enough developers to build plugings/mods for basic stuff (like your Aeva SMF mod)?

- what security expertise is on the team?

I really like this demo forum, and I'd love to be one of the first to use it when it's pushed to stable.  I ended up on this forum after looking for the latest Aeva mod, and got up to speed on the politics of SMF.

It's not unrealistic for our traffic to grow to a few million hits per month, so I want to make sure I make a good decision before we convert.  To sum up my position on my forum, I feel like I'm on a plane set on autopilot, and both pilots are dead.

The majority of the good ones get assimilated into the team, screwed over and leave. The slow release structure is related.

None whatsoever, except learning how to design mindfucked UI (Drupal)

Understanding the internals of PHP is no real benefit to writing stuff higher up, just as writing assembler probably won't help you write good stuff in higher level languages. I have a passing awareness of how the guts of the language work, but really, that's no substitute for decent programming style in general.

Caching, yes, pretty clued up on that.

Thing is, this is a FORK. It has a lot of SMF code still in it, a lot of SMF mentality and mindset and it's going to take a long time to phase that out, short of a complete rewrite.

Even much of the recent code still doesn't look particularly out of place from SMF, though we're finally moving stuff to using classes and exceptions, stuff that SMF never used because until recently it was supporting ridiculously old versions of PHP (SMF 2.0 will still largely work on PHP 4.1 and 4.2 and should be fully functional on 4.3+, even taking into account the magic loader that rewrites PHP 5.0 style classes with scoping to make them largely work with PHP 4.x)

There already is, written by the guy who used to write converters for SMF ;)

It's just been two guys (well, one guy the whole time, one guy sort of part time) the whole way through. But between the two of us we've worked on the biggest plugins for SMF; Nao did Aeva, I did SimpleDesk (that little helpdesk that even SMF themselves use)

Hard question to answer, since there's no security 'certification' per se for web design. What I can tell you is that in a couple of weeks I'm taking the Zend certification for PHP and in previous mock exams I've done, my security knowledge always came out as excellent. I try and design things for security first. For example the plugin system I've been doing is being engineered to allow people to upload plugins through a web interface but it jumps through a lot of hoops to avoid writing things as owned by the webserver, to prevent them being attacked on a shared server.

But the fact I've been known to report security issues to SMF (one of mine prompted SMF 2.0 RC5), I've also been known to review all the vulns I could find for SMF 2.0 and verify whether they are genuine or not. So, I guess you could say that there's a decent amount of security experience around here.

Nao was Aeva's developer/maintainer, I just came along and wrote a bunch of mods for SMF as well as being a reviewer on their Customiser team, writing their helpdesk and so on. In the scheme of things, Nao's the star here.

I would note that this isn't just a demo forum, it is the *primary* forum for the site, where we discuss features and so on. Sometimes we discuss them with an awful lot of passion, because we've put a lot of time into this and it frustrates us when that time doesn't work out so well.

That is pretty much where SMF is right now. I don't want to explain more, but they're not in a good place right now, and anyone watching their Github repo would probably understand where the problems are right now.

As a C developer, understanding how the compiler did stuff did affect how I wrote in C, for example.  For PHP, as long as you know how f*d PHP is, I guess that would suffice.  I think a PHP developer, for example, should know what a zVal is -- but you're right -- as long as you write clean and optimal code, it's all good.

Well, I hope you don't get hit by a bus!  Do you anticipate on letting others into your codebase as your community grows?  Do you have folks you have worked with in the past that will come over?

Therein lies an interesting road to madness. Do you write something because of how the parser will handle it, or do you write something because it's readable and maintainable and let the parser do its thing? Bonus question: does that mean a PHP developer should keep in touch with the changes of PHP's own code beyond keeping up with bug fixes and changelogs and regularly rewrite code?

Yes, I have an understanding of what a zVal is, but it has little real impact on how I write code day to day.

It's interesting, actually. One of the challenges I've faced lately is working with PclZip. I've made my dissatisfaction known here about it, but as much as I dislike it as *PHP* code, I can't argue that there is a logic behind how it's written; it is essentially written how one might write C code - every function accepts pretty much every non-scalar parameter as a reference, uses $p_ prefixes to indicate what are references from outside vs $v_ prefixes for local variables, and each function returns 0 for success and non-zero to denote error with the actual error being denoted by the return value specifically, along with passing options to functions through what in PHP terms is large abuse of variable function arguments and just parsing the list of responses against a list of known options and sanitising the values that come through thereafter.

In engineering terms, it probably works very closely to how PHP would handle the bytecode. But as far as maintainable, readable PHP goes, it's hard work - and in the last 10 years I've both written and read very ugly PHP.

For the most part, though, the problems that are born out of bad logic are not born out of misunderstanding how the parser works and writing code that doesn't translate efficiently, but simply out of writing bad logic. You can micro-optimise to fix a given routine, even refactor/rewrite it, but there are just some problems that are too large to be fixed like that. We have a couple hanging around right now like that where the logic has sort of brought us to a cyclic dependency that can only be fixed by large scale changes. But that's the nature of the beast.

Tell you one thing though. There's the likes of XenForo and IPB which are written in a much more 'modern' style and much more in line with the 'way of things' by the book, as it were, but it's less about practicality and performance for them, enforcing consistency and style becomes more important. I don't have any hard benchmarks but the limited performance tests I've done on my own stuff suggests that both SMF and Wedge outperform IPB quite well most of the time and are more than comparable to XenForo. "More correct" doesn't necessarily mean better ;)

Well, there are several people who have read only access to the main SVN tree, and several more who've had private alphas but they're milestones rather than current bleeding edge.

As far as the us-and-them goes... there's a few that hang out here occasionally, and we've been known to share bug reports on occasion, but it's interesting to note what is going on behind the scenes.

For those of you wondering what I mean, I'll just say the word Elkarte and leave the rest to you.

I'd love for you to dish, but I guess you want to keep it close to the chest.

Hey, regarding the quoting, is there a way to get rid of nesting quotes?

Quote

I'd love for you to dish, but I guess you want to keep it close to the chest.

It's not my story to tell. But the public information is enough to figure out the general story even if not the specifics.

Quote

Hey, regarding the quoting, is there a way to get rid of nesting quotes?

Yes, the same as in SMF - in the admin panel there is an option to remove nested quotes. We have removed some SMF 'features', but not that.

Hey, nice to see another programmer here!

Does over a dozen plugins count? :P