Uh Oh! It appears you're not connected to the internet!
Sorry! We currently have more users than we can cope with. You can either wait until a space becomes available or come back later. We will be upgrading our servers to cope with this soon!
You got the boot! Click to connect back up...
Please contact an administrator, You are not authorised to login via this IP address
Already have an account?
Click here to login
Don't have an account?
Click here to sign up
Go check your email!
Oops! We don't know your email address, We can't send you a new password! Contact an Admin
Set Profile Picture
Select An Image
Confirm End Of Friendship
Chat To Us
Prefer to chat anonymously?
Read all about it, See what the good people at Project Peach have to say
OUR GOALS (2011)
Did we even get close to achieving software development utopia?
2011: Back to the Future
Introductions: Who are we?
Been in software engineering professionally since 1987, writing code!
Consultant at Yorkshire Water, Unilever, Rapiscan Systems, Senior Engineer at IBM and several Startups
Diverse commercial projects, schematics, b2b connectivity, cognos business intelligence, RadNuke detectors
Skillset C, C++, win APIs for coding on windows & linux/unix. GUI and backend server work.
Currently framework architect, c++ server framework coding, sales.
Professional software developer since 2005
Software engineer at AutoCab, consulant at Amey, Rapiscan Systems and several Startups
Diverse commercial projects, autocab, denials management, amey management, RadNuke R&D
Skillset C, C++, JS, HTML5, CSS3, SASS, web development stack, Full Stack
Currently our graphic artist, server and browser framework developer
Been working together as a team, on and off, since 2003. Our current startup since late 2011. Project Peach born. Most of what follows is an edited version of our programming mission statement from back in 2011 and where we were at back in 2014. It formed the basis of a presentation of live webapps for the UK Met Office in that year. Read on...
Project Peach: What?
A stealth startup owned and funded entirely by ourselves with no outside investment. >£400k so far.
Five years developing our framework to accomplish the aims defined below
At the point of becoming a commercial company with our first web applications delivered
Looking to spread the word about our modern realtime framework and modern development processes
Project Peach: Aims
Investigate and use the latest technologies to create a more modern development process. Help us all build better apps!
Use html5 standards/specifications as a starting point to design and build our framework
Accept that the modern web browser is not simply a web browser, it's a fully fledged frontend GUI development studio
Create a client framework, server framework and the messaging connectivity between
Create live, realtime, web applications which are more like applications then websites. Use push messaging NOT polling
Use 'open source' software for all our library requirements. Make our framework 'open source' to our clients not free software
Not to be tied to any proprietary technology or companies technology! MS .NET example. Always have the source code
Not be tied to any particular OS for either client or server framework runtime requirements
Not to be tied to any particular browser, just a modern browser! Limited backwards support is acceptable!
To be scale our application GUI gracefully across all devices, mobile, tablet, laptop with one source code base
Remove the need to build apps for specific devices, one application fits all
Clear demarcation between markup, presentation/visual formatting and code. Graphic designer vs coder
Work as well with a finger as with a mouse pointer
To scale well as an application, run locally, run Intranet or Internet
Scale well using infrastructure upgrading, suitable for server farming
High performance messaging server, multi-threaded, exception safe and software scalable
Additions and improvements to our framework are available to all framework products and visa versa
To speed up development time by providing coding libraries and out of the box functionality
Proof. Can we migrate any applications we have previously written into our framework? YES
Modern Browsers for UI/UX
Chrome, safari, opera, firefox, IE11 plus mobile versions. All self updating browsers. All implementing html5 specifications
What's a browser for? Simply feeding from a web server or more? Request files, html, images and render document. historically YES
With html5 websockets there is a permanent browser/server connection to send and receive messages independant of the Web server!
Access to hardware like webcam, location services GPS, etc. In browser programmable access to hardware resources
Software implementations of client side html5 specifications like webrtc, websockets, notifications, localstorage, etc
Design UI/UX in a visual interactive way using html and css
Web components: shadow DOM, html templates, reusable widgets from html/css/js. Example html form controls all widgets
SCSS: sassy stylesheets adding variables, inheritance, functions, and parameterisation to CSS. Chrome dev tools native support
Web Servers and Websockets for applications
Web servers are great for file serving. Connect, Get, Disconnect. We can use this to host static files like images and pages
Web servers can run code. PHP, .NET, ISAPI, .... Same model of connect and disconnect but useful for templated pages
Web server connections can be upgraded to web socket connections via a standard and a handshake. Permanent connection
Websocket servers are simple socket servers. listen, accept, connect. Tried and tested technology
A permanent connection to the server provides a scalable application messaging opportunity
A websocket server can preserve state natively for the connected browser
Browsers to server connections form a network of indirectly connected computers for messaging opportunities
A web socket server is a native application. We can build shared data models, access databases, map messages to events
Make a distinction between the websocket application and the application specifics to run multiple instances
Reuse server side business logic code and create stunning new browser application interfaces
What can we build today?
A traditional hyperlinked website that simply uses a web server and the transcient http connection
A traditional website using some behind the scenes web access XMLHTTPRequest/AJAX to avoid server roundtrips for data - polling
A hybrid website/webapp mix. Mostly website with additional 'push' live features via websockets
A webapp more like application than website, code and data models on server and client
A framework webapp with optional built in features out of the box, skype, IM, private social media, live controls, live push data
We can take a traditional windows application, modernise the UI in browser and reuse the business logic code on the server
Host the processing where it makes sense on the server or locally in the client browser, native code or interpreted JS code
Render a visualisation of an object model in a browser whose dynamic data model is server hosted, push only updates - live
Create indirect and direct connections of browser to server to browser. Inter-browser messaging and direct browser messaging
A webapp can work on a single machine, local networks or over the Internet
Live data forms with multiuser concurrent editing with realtime push updating
Traditional database application via our abstracted DB access classes. Currently sqllite support. MySQL just needs implementation
Limited only by our imagination...
What's your framework then?
Messaging system core. Browser to server to browser realtime permanent connection
A server component
A core messaging websockets server connecting browsers to server. A high performance implementation of websocket server spec.
A mechanism to map messages to fire events, run code handlers on the server
A map of connected browsers and a routing mechanism to pass messages to other browsers. Pass through
Generate outbound messages in response to server events and pass to subscribed browsers
Our applications are not fixed at the point of production, both client and server side code inherit from the framework
New framework features, tested and proved in CashClamber, are automatically included in successive builds of application types
New application features for specific project, are generalised if useful, and feedback into the framework and other applications
All framework applications continue to grow with improvements in our framework
Reusable common forms and controls
A library of common UI/UX elements that can be reused on different application types and projects
Our UI controls are implemented both in the client JS and Server application core using messaging to interact
UI controls are object orientated both in JS and server code for further derivation without code duplication
All UI elements are skinned using CSS so the same control can appear cosmetically different per application type
Special live and shareable controls are available. Handle UI concurrency out of the box. Share across multiple dialogs
One more small step to move our controls shadow DOM, imports and templates. Stock controls as web resources. Self containment
Application Instance Manager
Allow more than one application instance to run on the same server. All with unique friends, newsfeed, data...
Each application instance has the same webserver html but different wording and skinning. Look different
Example. Host multiple shops for the same company with the organisation. Host multiple tailored clients on the same hosting
Allows a client to reuse the same VPS for multiple clients. Sell the application as a server on a subscription model
Allow an superuser administrator control over the running instances. Start, stop, create easily
Allow disparate types of application instances. Host multiple applications types and instances on the same server
Websocket connections are sticky. Web server connections are not sticky (to a point). Web farm is easier for web server
Multiple web servers behind load balancing switch(s) must route messages to the same intial connection server. Configuration
A server farm must distribute a routing directory. A map of connections to servers and re-route messages
Shared single redis server in redis layer (DMZ2) which routes messages via a directory of WS layer (DMZ1) connections
Multiple load balance redis servers in redis layer with shared memory or DB directory lookup
Clustered LB redis servers in redis layer. Each has connection directory copy mirror
Project Peach live website. Our management software running on top of all our live realtime sites
Dashboard monitoring of all our servers, AIM, Admin panels. Access to all AIMs and admin panels
Using allowable cross domain websocket messaging live monitoring of every webapp we create in realtime
Ultimate destination for all admin alerts. Exceptions and errors are sent here. Fix client problems before bug report
Central point of communication between Project Peach and our client admins. VoIP, IM, remote desktop in webapp
Heartbeat and system health constantly monitored. Support can support effectively
And in 2017?
We've not been idle since 2014. We've been constantly building both technical architecture, infrastructure and both writing / refactoring our code base constantly. We've fine tuned and created vertical packages like our live eCommerce solution. There's just too much to detail here. If you're as forward thinking as the Met Office were back in 2014, we'll blow you away with a demo of our 2017 live webapp framework. Want to help us grow? We're all ears!
Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.