What Relationship?
Javamancy and its sister sites are currently re-evaluating their relationship with a certain organization, after more than nine (9) years.
More news on this in a few days…
Javamancy and its sister sites are currently re-evaluating their relationship with a certain organization, after more than nine (9) years.
More news on this in a few days…
Here’s an interesting proposal:
If you were to create a portal for developers to congregate to describe their current and desired tools to ply their science/craft, what would it consist of?
For those “in the know”, the Inner.DevPal.Net site has been up and running for several days at this point.
E-mail me your thoughts/comments/ideas about it. Thanks!
Earlier today, somebody asked why I bother to abide by WordPress development guidelines and a lot of the “modularity” (master-slave) relationships that WP theme customization folks rely upon… especially given the fact that DevPal CM build methodology allows for rapid code deployments and easily performs code overlays without penalty.
Simple: because the methodology does not care whether the modifications are made to be part of an overlay onto the base substrate, or whether the WP customization guidelines are in play and the code is kept sequestered in individual subdirectories.
Also, if any of the products were released into the wild (i.e., not for a private client or project), the construction and customization philosophy espoused by the WP dev bunches makes sense.
Does it make sense to allow Facebook unfettered/unvetted access to DevPal and Javamancy Web properties and Web services, or add an abstraction layer to protect the IP of people who like doing business with DevPal and Javamancy but aren’t happy with Facebook?
Why does it shock PHP developers that Javamancy (and the rest of DevPal, for that matter) uses Ant to build, customize, and assemble PHP Web applications, like WordPress?
It’s a thing that makes us go, “Hmm…”
Externalizing DevPal’s internal dev and demo environments…
I’ve been toying this the concept of allowing the public to view some, maybe even much, of DevPal’s internal demo environments that manage or deal with OTS and FOSS packages. More potentially problematic would be externalizing the internal dev environments, many which have some dangerous software that most likely should not be given free reign on the Internet.
Plotting out the new architectural roadmap for the DevPal sites…
It’s both fun and exasperating at the same time. Particularly apportioning LoE’s and determining feature sets. But don’t worry: Javamancy mini is considered stable…