<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to Process</title><link>https://sourceforge.net/p/rupy/wiki/Process/</link><description>Recent changes to Process</description><atom:link href="https://sourceforge.net/p/rupy/wiki/Process/feed" rel="self"/><language>en</language><lastBuildDate>Fri, 13 Mar 2015 09:59:54 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/rupy/wiki/Process/feed" rel="self" type="application/rss+xml"/><item><title>Process modified by Anonymous</title><link>https://sourceforge.net/p/rupy/wiki/Process/</link><description>&lt;div class="markdown_content"&gt;&lt;h3 id="146-guide"&gt;1. Guide&lt;/h3&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;µSOA1&lt;/strong&gt;: &lt;em&gt;One developer per microservice.&lt;strong&gt;2&lt;/strong&gt;&lt;/em&gt; HTTP is the only interface between &lt;em&gt;everything&lt;/em&gt;. &lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Agile&lt;/strong&gt;: You need to be able to hot-deploy &lt;em&gt;everywhere&lt;/em&gt; because you'll want to work with others remotely at high iteration speeds. &lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Architecture&lt;/strong&gt;: The developer is completely free to choose any software (languages, tools, persistence etc.) of the service. &lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Turnaround&lt;/strong&gt;: Maximum build &amp;amp; deploy time on &lt;em&gt;live&lt;/em&gt; is how long it takes for you to switch to the test client. (1-2 seconds) &lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Ownership&lt;/strong&gt;: The developer owns and is responsible for the service &lt;em&gt;everywhere&lt;/em&gt; at all times. &lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Errors&lt;/strong&gt;: Should be pushed from each live client to the service developers mobile phone in realtime. &lt;/li&gt;
&lt;li&gt;&lt;strong&gt;TDD&lt;/strong&gt;: Test only what makes development slip due to complexity. &lt;/li&gt;
&lt;/ol&gt;
&lt;h3 id="246-manage"&gt;2. Manage&lt;/h3&gt;
&lt;ol&gt;
&lt;li&gt;The data -producer, -consumer and developer trio have 1 minute per person remote&lt;strong&gt;3&lt;/strong&gt; daily yester/morrow meetings. &lt;/li&gt;
&lt;li&gt;No other mandatory scheduled meetings. &lt;/li&gt;
&lt;li&gt;You should be able to work from home. &lt;/li&gt;
&lt;li&gt;If you finish quicker than expected, you own that remaining time. &lt;/li&gt;
&lt;li&gt;No documentation. &lt;em&gt;Automatic&lt;/em&gt; &lt;a class="" href="http://sprout.rupy.se/api" rel="nofollow"&gt;API&lt;/a&gt;. &lt;/li&gt;
&lt;/ol&gt;
&lt;h3 id="346-store"&gt;3. Store&lt;/h3&gt;
&lt;ol&gt;
&lt;li&gt;If &lt;a class="" href="https://code.google.com/p/rupy/wiki/Persistence" rel="nofollow"&gt;persistence&lt;/a&gt; can be a file, make it a file. &lt;/li&gt;
&lt;li&gt;If you need: &lt;ul&gt;
&lt;li&gt;Index; use the file system. &lt;/li&gt;
&lt;li&gt;Relations; use a graph. &lt;/li&gt;
&lt;li&gt;Full text search; combine the &lt;a class="" href="http://root.rupy.se/node/data/text/full%20text%20search" rel="nofollow"&gt;two&lt;/a&gt;! &lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Your persistence should use HTTP. &lt;/li&gt;
&lt;/ol&gt;
&lt;h3 id="446-develop"&gt;4. Develop&lt;/h3&gt;
&lt;ol&gt;
&lt;li&gt;Each module describes it's own use: f.ex. if you browse to &lt;a class="" href="http://sprout.rupy.se/login" rel="nofollow"&gt;/login&lt;/a&gt; you should be able to login! (&lt;a class="" href="http://rupy.se/sprout/se/rupy/sprout/Node.html" rel="nofollow"&gt;model&lt;/a&gt;, &lt;a class="" href="https://code.google.com/p/sprout/source/browse/trunk/res/jar/login.html" rel="nofollow"&gt;view&lt;/a&gt; and &lt;a class="" href="https://code.google.com/p/sprout/source/browse/trunk/src/se/rupy/sprout/User.java#207" rel="nofollow"&gt;controller&lt;/a&gt;) &lt;/li&gt;
&lt;li&gt;Use async for: &lt;ul&gt;
&lt;li&gt;Server &lt;a class="" href="https://code.google.com/p/rupy/wiki/AsyncResponse" rel="nofollow"&gt;response&lt;/a&gt;; if you have high iowait or realtime services. &lt;/li&gt;
&lt;li&gt;Client &lt;a class="" href="https://code.google.com/p/rupy/source/browse/trunk/src/se/rupy/http/Async.java" rel="nofollow"&gt;requests&lt;/a&gt;; if you can concurrently build the response to reduce latency. &lt;/li&gt;
&lt;li&gt;For top performance and speed &lt;a class="" href="https://code.google.com/p/rupy/wiki/Fuse" rel="nofollow"&gt;FUSE&lt;/a&gt; both. &lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Use the same development keyboard and OS everywhere. &lt;/li&gt;
&lt;li&gt;Use JavaScript injection for modularity, over; chunked response, CO-XHR or even XSS (careful with the cookies though). &lt;/li&gt;
&lt;/ol&gt;
&lt;h3 id="546-host"&gt;5. Host&lt;/h3&gt;
&lt;ol&gt;
&lt;li&gt;Minimum two subdomains per service (f.ex. dev.&lt;code&gt;&amp;lt;&lt;/code&gt;name&lt;code&gt;&amp;gt;&lt;/code&gt;.host.com and &lt;code&gt;&amp;lt;&lt;/code&gt;name&lt;code&gt;&amp;gt;&lt;/code&gt;.host.com): &lt;ul&gt;
&lt;li&gt;On same server provider. &lt;/li&gt;
&lt;li&gt;Port 80 only. &lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Increase socket memory if you &lt;a class="" href="https://code.google.com/p/rupy/wiki/ServeLargeFiles" rel="nofollow"&gt;serve large files&lt;/a&gt;. &lt;/li&gt;
&lt;li&gt;If it makes economical sense to use Akamai your software is probably bad. &lt;/li&gt;
&lt;li&gt;DNS Roundrobin across backbones allows for 100% uptime. But this requires a new kind of real-time distributed &lt;a class="" href="https://code.google.com/p/rupy/wiki/Persistence" rel="nofollow"&gt;persistence&lt;/a&gt;. &lt;/li&gt;
&lt;li&gt;Install, configure, &lt;a class="" href="http://monitor.rupy.se" rel="nofollow"&gt;monitor&lt;/a&gt; and notify yourself; even the hardcore &lt;a class="" href="http://one.rupy.se/panel" rel="nofollow"&gt;stuff&lt;/a&gt;. &lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;&lt;strong&gt;1&lt;/strong&gt; Micro Service Oriented Architecture an evolution of &lt;a class="" href="http://martinfowler.com/articles/microservices.html" rel="nofollow"&gt;Microservices&lt;/a&gt; and &lt;a class="" href="http://queue.acm.org/detail.cfm?id=1142065" rel="nofollow"&gt;SOA&lt;/a&gt;.&lt;br /&gt;
&lt;strong&gt;2&lt;/strong&gt; If two people choose the exact same tools they can work on the same service; the whole point is that nobody should have to compromise with their tools. The work should not be to configure others tools, but to design a specific product with clear separation of responsibilities between developers.&lt;br /&gt;
&lt;strong&gt;3&lt;/strong&gt; &lt;a class="" href="https://www.youtube.com/watch?v=5XD2kNopsUs" rel="nofollow"&gt;Jason Fried&lt;/a&gt;, &lt;a class="" href="https://weworkremotely.com" rel="nofollow"&gt;We Work Remotely&lt;/a&gt;, &lt;a class="" href="http://stet.editorially.com/articles/making-remote-teams-work" rel="nofollow"&gt;Mandy Brown&lt;/a&gt;.&lt;br /&gt;
&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anonymous</dc:creator><pubDate>Fri, 13 Mar 2015 09:59:54 -0000</pubDate><guid>https://sourceforge.net29055bc6c75b6415ee17291c077716f012b828e3</guid></item></channel></rss>