In developing a small concept of producing a DevOps server for the environment of a single Small Office/Home Office (SOHO) network, in the past couple of days I've reviewing a concept of installing Gitblit, JSPWiki, Roller, and Activiti, as web services, then to develop a minimalist web-based portal front-end for integrating those individual web service components into a single "User experience". These components would be installed, originally, to one of my old laptops, it serving a dual-purpose role as an old laptop retained of my own purchase -- now a manner of a sentimental artifact, sure -- presently applied as a FreeBSD server on a SOHO Local Area Network (LAN).
The local web-type services, of course, would not be the only features of the same server's Service mix, as it would also publish a Git service from within a FreeBSD sandbox. The Git service, of course, could be published from a sandbox maintained in a manner separate from the host's web server sandbox -- that, as with a small amount of software to provide a filesystem bridge, between the two -- both sandboxes operating on the same computing machine, however, with both being procedural isolated from the "Sandbox controller" server. Even in so much as a design for such application of the FreeBSD sandbox, i.e jails framework, it might already represent a manner of a component-oriented software service design, though it is not yet in every ways a detailed software service design.
I've favored this design, due to its minimalist nature and its development singularly in the Java programming language. I'd begun the design, after reading a comment -- from 2012 -- by James Gosling, a positive comment about Gitblit [Gosling2012PapaMau] Of course, a positive comment by one of the original developers of the Java programming language may seem to carry for some mileage.
In my own small software design work, proceeding from a review of the Gitblit web services component, I'd even developed a clever name for the design, a DevOps portal design for my own LAN, but such that should be scaleable beyond the "Single use" -- naming the design, "Glister," after an artifact of the Heritage Universe, a series of science fiction books written by a physicist, Charles Sheffield. In a context of the story of the Heritage Universe books, Glister is an Artifact that appears early in the story. In a context of a SOHO network, Glister has been -- thus far -- simply an easy-to-remember name for a single service design. As I've developed a substantial amount of writing about the design, in my Evernote notebooks, it is not a design I would want to abandon hastily.
The design of the Glister DevOps server, in some ways, it mirrors the design of the EmForge Portal. In a manner, both designs would introduce a Business Process Management (BPM) component to the conventional service mix of a wiki, web log, issue tracking, and web-based source code review service -- as also seen, with some slight differences, in Edgewall's Trac, different at least in regards to the implementation of each service of the respective service mix. Of course, Trac favors the Subversion change management service, as does EmForge -- whereas Glister would apply Git, with a Gitblit web interface providing a light-weight localized service for immediate web-based source code review.
Of course, the issue tracking feature might not seem as apparent as the novel "Other features" of the architecture.
In the Glister portal, Activiti would provide a BPM management interface. Thus, it may seem to effectively mirror the the BPM component of EmForge.
Considering that the "Issue tracking" features of the Glister architecture may seem -- in ways -- very much obscured of the novelty of some of the other components of the architecture, perhaps the "Issue tracking" service could not be the main "Selling point", if it would be presented as all of a "Free beer" model.* Regardless, I've estimated that it may be relatively easy to develop an issue-tracking front-end for Activiti -- whether to emulate Bugzilla, Request Tracker, GNATS, or any other normative issue tracking service -- such that would be developed, originally, for issue tracking about individual Ports, such as available on the FreeBSD operating system and such as would be installed to an individual SOHO network.
Though I am not inclined to present it as if it was any manner of a "Zero-Sum Free Beer Return" process -- and well would such a process be a novelty, in itself, of all the spontaneous things -- I suppose that I could try to market it is as so, whatever I may eventually be able to develop of the Glister server baseline. Not as if to exploit "Free Beer," it is already a small effort at making use of a small number of existing software components, in developing a manner of an immediately "New" component -- so far, as to develop a "New", and in-some-ways "Unique" service design, then as to proceed towards an effort in producing and maintaining that design in its implementation, there in regards to some terms of real software integration, and documentation, and software distribution, and issue tracking. Maybe it would not seem immediately "Fun," in such a perspective.
I notice, presently, that the Jenkins server -- such that I may wish to denote as it being an alternative to an independent design of a DevOps server, such as Glister proposes to implement, and such as is implemented of EmForge -- that the Jenkins server has recently found an application in the FreeBSD project. If it is a project trusted by the FreeBSD project, and if it may serve a role in mitigating my own development burden, and as I may happen to personally trust the OS distributed by the FreeBSD project, in a far ways, thus I've begun to consider applying Jenkins, albeit then to an effect of by-in-large abandoning the Glister service design.
Though the Glister service design, in its exact and present composition, has not existed for any long period of time -- this specific design has been in development for all of a couple of days, now -- I'd thought it might serve as a manner of a "Go-getter" project, though, as well as a nice minimalist design for a convenient web service on a local area network (LAN). The note about Gitblit, I'd thought, it had seemed to convey so much of the original goodwill that was ever demonstrated of the Java developer community, at least as in the duration up to which the Sun Microsystems company -- the original "Shop" in developing Java -- was acquired by Oracle.
Whereas the latter corporate institution, Oracle, may -- in some manners of a metaphor onto science fiction -- that the Oracle company might seem to resemble an archetype much like the character of CLU in the TRON: Legacy universe, and though perhaps I'm the only person seeing it as so, but in no ambiguous terms: I miss the goodwill of the original Java developer community. That a programming language such as was originally developed to an effect of a web browser plug-in -- with regards to so much as the Java applet origins of the Java programming language -- that a single programming language, as such, has weathered all the tides of Enterprise trends and gone so far as to find an application in an embedded/mechatronic architecture presently continuing an expedition to Mars? Who could have expected such an outcome of a Java applet programming language?
In any linear, even post hoc analysis, how could such a thing have become? and what has been lost of the goodwill of the original Sun Microsystems developer community, in the years since the acquisition by Oracle? Moreover, how much of the original brainpower of Sun, in effect, had "Jumped off the ship" once the Oracle acquisition was finalized? and today, does Oracle still try to discredit the nature of free/open source software engineering, but that may be where they could find any of the staff that left Oracle? Have we not learned anything of this process, as yet?
Towards considering how the Glister service design might scale beyond a context of an individual LAN, it may be -- in that context -- that I might wish to entrust the Jenkins web services as for those web services to not only present a novel web-facing interface, but also ... but no, it may be simply the novelty of its web-facing interface that would draw my own attention more to Jenkins, as any alternative to the minimalistic design of the Glister service mix.
Candidly, I am a little worried about installing Jenkins on my own SOHO LAN, as -- even with its full free/open source codebase -- I do not know if it is such a kitchen sink I may actually need to install. Not to discredit its component-oriented design, though I am in any ways nonplussed by its marketing. I do not know if a Jenkins instance would actually "Do much" on my LAN, except if it may represent something of a novelty -- and yet, would the Glister design be any less so? If it may be any less of a novelty, and if it may be any more of a producible gain -- to my own manners of personal perspective -- but even if it may need "A lot more welding," as to "Put the thing together," for the "Thing" being a "DIY" component-oriented design of a lightweight DevOps server, maybe it's not too far past the sunset of Sun.
Personally, I think that a design strategy of "Everything and the kitchen sink" would not be ideal for a design of a light-duty/low-usage software service for an independent network services environment. Thus, personally, I've begun to "shy away from" so many Java Enterprise Kitchen Sink Portal architectures and the kitchen sink style of DevOps services, likewise, in considering any "Forward" designs for network services and -- in that context -- also web services.
I wouldn't want to seem too hasty in abandoning the concept of applying Jenkins, immediately. No sales lost of it, I would prefer to resume the Glister service design, and to keep my design table "Lightweight."
* The phrase resounds, even of free/open source software component systems: Caveat Emptor
Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts
Friday, October 16, 2015
Thursday, July 23, 2015
Towards a DITA OT Port for FreeBSD -- But First, The Larch
Corresponding to a beginning of a development of a personal business plan, formally starting today, I've set aside my own edition of the [plug start] Samsung Galaxy S 8.4 Tablet -- an Android tablet -- and its seat-friendly, tabletop-friendly, all-around outdoors-friendly Griffin All-Terrain case [plug end] -- furthermore, leaving aside the Evernote app -- likewise, to sit down at my FreeBSD notebook -- for a short time -- indoors. It's a kind of a "Pivot day," in my own small, individual corner of the world. I've subscribed to Safari Books Online, and have begun to develop an ongoing books list.
In beginning to read one item in that list, I've queued up what is my first book to read about the Darwin Information Typing Architecture (DITA), in my own Safari books queue, namely the text: DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA.
Corresponding to that new books subscription, yesterday I'd begun developing a draft edition for another 'blog article -- that article, focusing about DITA, as in developing a concept of DITA architecture and DITA in applications. That was in using the Blogaway app (Pro edition), on my tablet. I'm afraid it may as well remain in an unpublished draft edition, that article. Candidly -- in no short time after I've signed up with the Safari Books subscription service and begun reading about DITA -- presently, it's developed from an academic pursuit into a project idea. Likewise, it's such that I'd like to share about, as a project idea.
Of course, a project would not be able to take up a life of its own, in such short time. Beside the introduction that I'd tried to develop, in that unpbulished 'blog article, yesterday, but in a shorter sense of overview: Personally, I have some albeit limited knowledge about technical writing -- as namely with regards to a small number of document formats, such as the DocBook SGML DTD and DocBook 5 RELAX NG XML schema. I'm fairly well familiar with XML, more broadly, as a markup format.
Previous to yesterday, I'd read a little bit about DITA. In a sense, I'd thought it seemed like a kind of a cheerful little ray of sunshine about narrative XML documentation formats, in broad -- a topic that there might not seem to be too many rays of sunshine about, typically. Candidly, on reading only some little about applications of the DITA schemas -- furthermore, in my being familiar with a style of hypermedia markup conventions as developed in DocBook -- I was a little put-off about some of the conventions of XML syntax developed in DITA. Mainly, there are the syntax and semantics of linking, in DITA information sets -- more specifically, a small number of elements and attributes in DITA, such that those elements and attributes may serve to provide "hooks" for content replacement in DITA processing models, as I've now begun to understand-- in a sense, those confuse me otherwise. I think there's a substantial difference in how DITA develops a concept of hypermedia linking, contrasted to the primarily ID/IDREF oriented hypermedia linking model in DocBook. I don't personally find myself able to "Leave it all to the editing platform," either -- my not being able to assume any manner of an opacity about the DITA markup format -- as I'm fairly certain that I may be editing a DITA markup file in a console-based text editor, at some point in time.
So, although those features of the DITA markup schemas may be such that I may find difficult to understand -- at least, at either of a first or second approach, in study -- now that I've found more of a friendly documentation about DITA and reviewed a couple of DITA document source trees, I'm fairly certain that I should be able to learn to proactively adapt my own hypermedia knowledge to adjust to the DITA document formats, even inasmuch as with regards to extending DITA.
It's on that note, then, that I am still trying to write around the "Long leap" of the following tasks, as I can forsee in my own "Next nine yards" about DITA:
The Oracle Java(R) launcher thing on Microsoft Windows 8.1 -- though it's cute, certainly -- it doesn't really change that impression, so much, not to my own point of view. Candidly, I still expect Oracle to be the monolithic corporation largely focused about a database platform, such that I've -- for a long time -- estimated of Oracle as a company. I don't think it makes any less of an Atlas-like shadow, with Oracle having acquired Sun. With Oracle now having demonstrated their own obvious lack of information with regards to FOSS and defense systems software, I might wish to trust Oracle to be moreover a Blind Atlas -- very worrisome, I think, worrisome if Oracle would set about to "Make New The Things."
So, knowing of a particular manner of a corporate monolith as such, looming up a little ways northward in California, and with some much of a knowledge of a broader world, I'm afraid I'm unable to join in the local Cool Team Parties. Even in avoiding any manner of a too locale-centric manner of a perspective about software development, but it still kind of "Creeps me out," about Java(R), if Oracle is really all the Enterprise as may I candidly estimate it to be.
If it may be possible to limit one's owns views to a sense of plainer principles, however -- inasmuch, to not make overmuch of a consideration as with regards to superstitions -- sure, Oracle might not be all of the scarily opaque commercial software institution that I might think of it as. Focusing if simply on the ongoing free/open source licensing of any products previously developed or adopted by Sun Microsystems -- such as Berkeley DB, for instance, in its free/open source licensing options -- there's a matter of software licensing, orthogonal to any company's own apparently political positions with regards to software development models.
Thus, there's a foot I can find, in my own sense of knowledge about software now licensed by Oracle -- a foot, at which I may be able to disembark from my own concerns with regards to Oracle's policies. If it could seem as though Oracle could become such as, "Like Old Microsoft, but a thousand times worse," there's what I'm worried about. Regardless, the free/open source licensed by Oracle as free/open source software, that much of software might endure any such shift -- as much as of any free/open software licensed originally by Sun Microsystems.
So, in something of a sense of an organizational view, maybe the goodwill "Vibe" that Sun developed could be just enough that it may endure even the acquisition by Oracle -- however far any developers and managers who would've been the parties directly developing such goodwill, and about a programming language moreover, however far "The Java Original Team" in and beyond Sun, may have been put off and away from Oracle.
If I'd thought as though the film TRON: Legacy may have been all of a metaphor about Apple, perhaps it could as well be a film interpreted as if about any other Silicon Valley empire of an enterprise -- Oracle, perhaps as like a CLU character nearly making Java break out so much that it would break apart?
I don't find myself able to ignore the apparent social implications of Sun's acquisition by Oracle -- it seeming even more worrisome, after Oracle tried to toss some mud to the US DoD, as denoted in an article once reported to Slashdot, mud as if about free open source software. The "Old Microsoft 2.o?" theme, thusly, it began in my own simple point of view about Oracle.
Clearly, Oracle "Owns" Java(R) as a trademark, today, but -- not even after the acquisition of Sun -- Oracle certainly does not own the history of the Java programming language. Thus, there's a broader sense of context, and nothing radical, about not looking too far into the Oracle.
So, maybe there's any plan for Java integration in LLVM. I'll have some research to develop, before I myself may develop any further work about Java(R) on a FreeBSD(R) operating system. The Brand Wars not begun again, they have not.
In beginning to read one item in that list, I've queued up what is my first book to read about the Darwin Information Typing Architecture (DITA), in my own Safari books queue, namely the text: DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA.
Corresponding to that new books subscription, yesterday I'd begun developing a draft edition for another 'blog article -- that article, focusing about DITA, as in developing a concept of DITA architecture and DITA in applications. That was in using the Blogaway app (Pro edition), on my tablet. I'm afraid it may as well remain in an unpublished draft edition, that article. Candidly -- in no short time after I've signed up with the Safari Books subscription service and begun reading about DITA -- presently, it's developed from an academic pursuit into a project idea. Likewise, it's such that I'd like to share about, as a project idea.
Of course, a project would not be able to take up a life of its own, in such short time. Beside the introduction that I'd tried to develop, in that unpbulished 'blog article, yesterday, but in a shorter sense of overview: Personally, I have some albeit limited knowledge about technical writing -- as namely with regards to a small number of document formats, such as the DocBook SGML DTD and DocBook 5 RELAX NG XML schema. I'm fairly well familiar with XML, more broadly, as a markup format.
Previous to yesterday, I'd read a little bit about DITA. In a sense, I'd thought it seemed like a kind of a cheerful little ray of sunshine about narrative XML documentation formats, in broad -- a topic that there might not seem to be too many rays of sunshine about, typically. Candidly, on reading only some little about applications of the DITA schemas -- furthermore, in my being familiar with a style of hypermedia markup conventions as developed in DocBook -- I was a little put-off about some of the conventions of XML syntax developed in DITA. Mainly, there are the syntax and semantics of linking, in DITA information sets -- more specifically, a small number of elements and attributes in DITA, such that those elements and attributes may serve to provide "hooks" for content replacement in DITA processing models, as I've now begun to understand-- in a sense, those confuse me otherwise. I think there's a substantial difference in how DITA develops a concept of hypermedia linking, contrasted to the primarily ID/IDREF oriented hypermedia linking model in DocBook. I don't personally find myself able to "Leave it all to the editing platform," either -- my not being able to assume any manner of an opacity about the DITA markup format -- as I'm fairly certain that I may be editing a DITA markup file in a console-based text editor, at some point in time.
So, although those features of the DITA markup schemas may be such that I may find difficult to understand -- at least, at either of a first or second approach, in study -- now that I've found more of a friendly documentation about DITA and reviewed a couple of DITA document source trees, I'm fairly certain that I should be able to learn to proactively adapt my own hypermedia knowledge to adjust to the DITA document formats, even inasmuch as with regards to extending DITA.
It's on that note, then, that I am still trying to write around the "Long leap" of the following tasks, as I can forsee in my own "Next nine yards" about DITA:
- Installing Java on my own FreeBSD notebook, with work-log, notes, and documentation references correspondingly
- Installing the DITA Open Tooolkit Tools onto the same notebook, likewise with a set of corresponding notes and references
- Likely beginning at least a local project for creating a FreeBSD port of DITA Open Tooolkit. This task, ultimately may entail a communication and further coordination with the FreeBSD Java(R) Project. As such, it's nothing I may approach in any of a too casual regards. Not to say overmuch about my own opinions of Oracle's style in commerce or software development -- however contrasted to the novel goodwill style of approach, as originally developed by Sun Microsystems -- I think Oracle's left me with a little bit of a bad impression, as to Oracle's position reportedly ever disfavoring developments in free/open source software (FOSS) namely in defense-oriented projects, and perhaps Oracle's own lack of information, as such, candidly.
The Oracle Java(R) launcher thing on Microsoft Windows 8.1 -- though it's cute, certainly -- it doesn't really change that impression, so much, not to my own point of view. Candidly, I still expect Oracle to be the monolithic corporation largely focused about a database platform, such that I've -- for a long time -- estimated of Oracle as a company. I don't think it makes any less of an Atlas-like shadow, with Oracle having acquired Sun. With Oracle now having demonstrated their own obvious lack of information with regards to FOSS and defense systems software, I might wish to trust Oracle to be moreover a Blind Atlas -- very worrisome, I think, worrisome if Oracle would set about to "Make New The Things."
So, knowing of a particular manner of a corporate monolith as such, looming up a little ways northward in California, and with some much of a knowledge of a broader world, I'm afraid I'm unable to join in the local Cool Team Parties. Even in avoiding any manner of a too locale-centric manner of a perspective about software development, but it still kind of "Creeps me out," about Java(R), if Oracle is really all the Enterprise as may I candidly estimate it to be.
If it may be possible to limit one's owns views to a sense of plainer principles, however -- inasmuch, to not make overmuch of a consideration as with regards to superstitions -- sure, Oracle might not be all of the scarily opaque commercial software institution that I might think of it as. Focusing if simply on the ongoing free/open source licensing of any products previously developed or adopted by Sun Microsystems -- such as Berkeley DB, for instance, in its free/open source licensing options -- there's a matter of software licensing, orthogonal to any company's own apparently political positions with regards to software development models.
Thus, there's a foot I can find, in my own sense of knowledge about software now licensed by Oracle -- a foot, at which I may be able to disembark from my own concerns with regards to Oracle's policies. If it could seem as though Oracle could become such as, "Like Old Microsoft, but a thousand times worse," there's what I'm worried about. Regardless, the free/open source licensed by Oracle as free/open source software, that much of software might endure any such shift -- as much as of any free/open software licensed originally by Sun Microsystems.
So, in something of a sense of an organizational view, maybe the goodwill "Vibe" that Sun developed could be just enough that it may endure even the acquisition by Oracle -- however far any developers and managers who would've been the parties directly developing such goodwill, and about a programming language moreover, however far "The Java Original Team" in and beyond Sun, may have been put off and away from Oracle.
If I'd thought as though the film TRON: Legacy may have been all of a metaphor about Apple, perhaps it could as well be a film interpreted as if about any other Silicon Valley empire of an enterprise -- Oracle, perhaps as like a CLU character nearly making Java break out so much that it would break apart?
I don't find myself able to ignore the apparent social implications of Sun's acquisition by Oracle -- it seeming even more worrisome, after Oracle tried to toss some mud to the US DoD, as denoted in an article once reported to Slashdot, mud as if about free open source software. The "Old Microsoft 2.o?" theme, thusly, it began in my own simple point of view about Oracle.
Clearly, Oracle "Owns" Java(R) as a trademark, today, but -- not even after the acquisition of Sun -- Oracle certainly does not own the history of the Java programming language. Thus, there's a broader sense of context, and nothing radical, about not looking too far into the Oracle.
So, maybe there's any plan for Java integration in LLVM. I'll have some research to develop, before I myself may develop any further work about Java(R) on a FreeBSD(R) operating system. The Brand Wars not begun again, they have not.
Tuesday, April 21, 2015
Hardpan Technologies and the Ex Libris Model – Bookshelf Concept and Service Architecture Design – Overview
Corresponding to development of the Hardpan Technologies web log ('blog), I would like to begin making some formal, public notes as with regards to a design not for a patent insomuch as it is a design for a bibliographical content management system. Today, I would wish to extend of that same design with a set of features for support of book sales – and that, without offending the sensitivities of libraries as institutions. So, a capital idea and a wave to the socialized state aside, the thing would focus on JCR and CORBA, firstly for data structures and personal content access, secondly for data services as may be provided on a heterogenous network medium of no too simple authenticity.
So, the initial server component would be implemented in Java, and the first service client toolkit may as well be implemented in Java, also. The server, in this design, would use ModeShape – nothing too specific in the data serialization layer, howrver. The server and the client would both use JacORB, and – ideally – the hosting operating system's Kerberos support, X.509 certificate model, and user interface.
It being implemented in Java, the first client application may not be available on iOS platforms. The intermediary IDL interfaces, however, could as well be implemented in C# for iOS platforms, and OS X platforms, and the desktop. Perhaps there's a port of Cocoatron for Android, too. The author is rather more immediately familiar with Java(r) toolchains, however, and the author does not have access to a normal XCode installation. So, initially, it will be implemented in the Java programming language, for Linux and FreeBSD servers and for Android mobile operating systems.
The author may or may not publish the Android app, at the Android app store. Initially, it will be installable for Android platforms, in application of the Android Studio IDE. "All smiles" for the newest innovations in development of the Gradle DSL for Android Studio applications, and the inevitable (?) Gradle-Ant and Gradle-Maven adapters, if one should wish to search around for such adaptive technology.
There's the architecture of it. It needs a name, too, and I have a name for it: Ex Libris, under the Hardpan label. Unique, huh? In that quality, it extends likewise of a design of a small model for access to, and user-unique creation and annotation of automotive notebooks in a user's own digital data model, in a manner ostensibly extensible for whole automotive crews, in applying CORBA, FreeBSD, Android, OBD-II libs, and the BeagleBone Black platform as a "Shop appliance" with a suitably stylish and functionally sturdy enclosure. No patent pending of this design, here licensed CC BY-SA 3.0.
Ex Libris, in its bookshelf features - no too long nod for BibTeX in Java.
Further design TBD.
Subscribe to:
Posts (Atom)