Jobeet: Difference between revisions

From Cibernética Americana
Jump to navigationJump to search
No edit summary
No edit summary
 
(46 intermediate revisions by the same user not shown)
Line 1: Line 1:
<div style="background-color: navy; color: white;">
<div style="background-color: #000066; color: white;">
== Original Function ==
== Jobeet/Jobim ==
{{TOCright}}
{{TOCright}}
"[http://www.ens.ro/2012/03/21/jobeet-tutorial-with-symfony2/ Jobeet2]" is what the Symfony developers call an example app that is a jobs site used as a model use case of their framework.  
<blockquote>
"[http://www.ens.ro/2012/03/21/jobeet-tutorial-with-symfony2/ Jobeet]" - originally, a Symfony tutorial app use case that is a [http://jobeet.org fully functional jobs site] .  
* [http://www.intelligentbee.com/blog/?s=jobeet Chapters up to 19] for Symphony 2.
* [http://www.intelligentbee.com/blog/?s=jobeet Chapters up to 19] for Symphony 2.
* [http://symfony.com/legacy/doc/jobeet/1_2?orm=Propel Original Jobeet (Symfony 1)]
* [http://symfony.com/legacy/doc/jobeet/1_2?orm=Propel Original Jobeet (Symfony 1)]
</blockquote>
The laconic/DRY design package in the next &sect; moves with working target. Other top level stuff below it.
== Day 0 Refactor for DS ==
[[File:jobeet.jpg|thumb|275px|left|Figure 1: Image of Sensio Jobeet]]
=== Story Rewrites / Additions ===
Jobeet for DS/PM is the heart of my use/implementation of the Public Job Shop. It retains much from the original, updated for Symfony 2 and inverted to its purpose in PM/PJS.
==== F0: The user is defined per PM ====
The tutorial did not really address registration or the like, there's actually only admin and anonymous class and the later are created and defined by use of the job posting form. In Jobim, a DS/PM SSO is operative.
==== F1: On the homepage, the user sees the active biz cases ====
The homepage displays the lines of biz and the cases the practitioner wants to pursue, exemplifying the refactoring of the original.
The search function is essentially the same but with the shown altered target domain and changes in the field targets as well.
==== F5: A user posts a job ====
The Post a Job form becomes sensitive to the users PM role:
===== none =====
The original function of the posting form is preserved for the anonymous user. The disposition of the post is determined by the practitioner and may be either kept local or posted to the general PJS.
===== customer =====
A posting by a customer is interpreted as a job order in PM/PJS.
===== merchant/peer =====
A posting by a user with this role is a job order which the user is handling as a broker.
==== F6 A user becomes a LoBAffiliate ====
[[File:jobim.jpg|thumb|275px|right|Figure 2: Image of Jobim]]
This is automatic based on the user having merchant/peer role.
==== F7 A LoBAffiliate  retrieves the current active job list  ====
The LoBA may select from either the practitioners cases, all those active in PJS , or both.
==== F8 A mobile app for iOS and Android ====
"Jobim", as a product name, is only used for the Cordova app of this feature:
# webviews for non-desktop form factors.
# adds a notification service to the affiliate service as originally defined and modified per the reinterpretation of affiliation 
# other controls/subfeatures. Small factors will have a small subset of other feature sets, but are the target of the notification service
==== F9 JobsSite Entity and Job Form changes for it  ====
Elements are added to both model and view to associate a jobs site such as Craigslist (that is the specific main target), Monster, etc. with the Job posting/order.
==== B3 An admin manages the affiliates and jobs sites pulls ====
PJS is populated largely from feeds from jobs sites stimulated by the job postings and collected either by agents running in the practitioners domains or by PJS itself (i.e. in my domains).
==== F10 PJS is populated with scrapes from job sites ====
This is done in PJS but the FE for it is here.
<hr>
== Meaning Here ==
== Meaning Here ==
 
<blockquote>
In the context of my softwares, the Jobeet original use case has been reworked to a completely different use case and a serious production function in my space:
In the context of my softwares, the Jobeet original use case has been reworked to a completely different use case and a serious production function in my space:


# Job Categories replaced by Lines of Business
# Job Categories replaced by Lines of Business
# Jobs are actual completed jobs in such lines of business
# Two kinds of Jobs, those entered via Doctrine programmatically  are actual completed jobs in such lines of business, others job orders
# CategoryAffiliate is replaced in the model by LoBAffiliate
# CategoryAffiliate is replaced in the model by LoBAffiliate


The first refactoring was <html><a href=http://jobeet.meansofproduction.biz>complete</a></html> in early 20114-04.
The first refactoring was <html><a href=http://jobeet.meansofproduction.biz>complete</a></html> in early 2014-05.


<blockquote>
<blockquote>
Line 19: Line 86:
</blockquote>
</blockquote>


</blockquote>
=== As a name for standard biz case working pattern ===
=== As a name for standard biz case working pattern ===


<blockquote>
I'm also using this term to refer to an encapsulation of the standardized approach I've developed for working jobs. The specific elements vary, but a timeline, sources in FishEye/Git, and a support network as a WordPress multisite and generally included.
I'm also using this term to refer to an encapsulation of the standardized approach I've developed for working jobs. The specific elements vary, but a timeline, sources in FishEye/Git, and a support network as a WordPress multisite and generally included.
</blockquote>


== Carries Symfony-Drupal Salient ==
== Carries Symfony-Drupal Salient ==
Line 30: Line 101:
Primary user identification is performed by a third party or transmitted cert.
Primary user identification is performed by a third party or transmitted cert.
</blockquote>
</blockquote>
<br>
</div>
</div>

Latest revision as of 13:32, 9 May 2014

Jobeet/Jobim

"Jobeet" - originally, a Symfony tutorial app use case that is a fully functional jobs site .

The laconic/DRY design package in the next § moves with working target. Other top level stuff below it.

Day 0 Refactor for DS

Figure 1: Image of Sensio Jobeet

Story Rewrites / Additions

Jobeet for DS/PM is the heart of my use/implementation of the Public Job Shop. It retains much from the original, updated for Symfony 2 and inverted to its purpose in PM/PJS.

F0: The user is defined per PM

The tutorial did not really address registration or the like, there's actually only admin and anonymous class and the later are created and defined by use of the job posting form. In Jobim, a DS/PM SSO is operative.

F1: On the homepage, the user sees the active biz cases

The homepage displays the lines of biz and the cases the practitioner wants to pursue, exemplifying the refactoring of the original.

The search function is essentially the same but with the shown altered target domain and changes in the field targets as well.


F5: A user posts a job

The Post a Job form becomes sensitive to the users PM role:

none

The original function of the posting form is preserved for the anonymous user. The disposition of the post is determined by the practitioner and may be either kept local or posted to the general PJS.

customer

A posting by a customer is interpreted as a job order in PM/PJS.

merchant/peer

A posting by a user with this role is a job order which the user is handling as a broker.

F6 A user becomes a LoBAffiliate

Figure 2: Image of Jobim

This is automatic based on the user having merchant/peer role.

F7 A LoBAffiliate retrieves the current active job list

The LoBA may select from either the practitioners cases, all those active in PJS , or both.

F8 A mobile app for iOS and Android

"Jobim", as a product name, is only used for the Cordova app of this feature:

  1. webviews for non-desktop form factors.
  2. adds a notification service to the affiliate service as originally defined and modified per the reinterpretation of affiliation
  3. other controls/subfeatures. Small factors will have a small subset of other feature sets, but are the target of the notification service

F9 JobsSite Entity and Job Form changes for it

Elements are added to both model and view to associate a jobs site such as Craigslist (that is the specific main target), Monster, etc. with the Job posting/order.

B3 An admin manages the affiliates and jobs sites pulls

PJS is populated largely from feeds from jobs sites stimulated by the job postings and collected either by agents running in the practitioners domains or by PJS itself (i.e. in my domains).

F10 PJS is populated with scrapes from job sites

This is done in PJS but the FE for it is here.


Meaning Here

In the context of my softwares, the Jobeet original use case has been reworked to a completely different use case and a serious production function in my space:

  1. Job Categories replaced by Lines of Business
  2. Two kinds of Jobs, those entered via Doctrine programmatically are actual completed jobs in such lines of business, others job orders
  3. CategoryAffiliate is replaced in the model by LoBAffiliate

The first refactoring was complete in early 2014-05.

The first refactoring is fairly superficial. The jewel of the refactoring centers on the LoBAffiliate and remodeling it as job sites such as Craigslist, monster, etc. The design intent is that the practitioner can look for related work and those recruiting can post jobs to the Public Market in addition to the attention of the specific practitioner, initially just me.

As a name for standard biz case working pattern

I'm also using this term to refer to an encapsulation of the standardized approach I've developed for working jobs. The specific elements vary, but a timeline, sources in FishEye/Git, and a support network as a WordPress multisite and generally included.

Carries Symfony-Drupal Salient

DS users (initially just my clients) will be able use my space without registration by supplying a single secret, generally known on a group basis. They then can access any resource for which they know another group secret, supplied either operationally and implicitly such as in a URI path member or explicitly bu supplying the role name/id secret.

Primary user identification is performed by a third party or transmitted cert.