In the first scene of the novel, The Picture of Dorian Gray (1891), the painter Basil Hallward confesses to his friend Lord Henry Wotton why he cannot exhibit the portrait of the eponymous hero. Basil admits, ‘Where there is merely love, they would see something evil, where there is spectacular passion, they would suggest something vile’ (Wilde, 1889–90: 21). This striking line, among many others that carry homoerotic innuendos, never appears in print. It is excised during Oscar Wilde’s revision process, along with other suggestions of homoeroticism between the three main characters of the story. The textual scholarship on this revision process generally agrees that Wilde neutralizes Basil’s erotic fascination with Dorian by transforming it into aesthetic appreciation. In particular, Nicolas Ruddick argues that Wilde aestheticizes Dorian in order to emphasize a moral about the dangers of vanity at the expense of another, more covert moral about the liberalization of homosexuality. Ruddick explains that, while the moral about vanity ‘dramatize[s] the disastrous consequences of the preference of the beautiful at the expense of the good’, the other moral about homosexuality ‘explores the destructive effects of the clandestine or closeted life’ (Ruddick, 2003: 126, 128). According to Ruddick, the novel’s famous portrait indexes the convergence of the two morals: ‘the appalling changes to Dorian’s painted image … strongly suggest that the unspeakable practices indulged in by the protagonist are unspeakable in themselves’ (129).
To interrogate Wilde’s treatment of the homoerotic elements, this paper examines his revisions across the first chapter of the manuscript of The Picture of Dorian Gray (1889–90). I use an electronic editing tool called the Text Encoding Initiative (TEI, explained further below) to register and describe Wilde’s revisions. My project uses the TEI ‘markup’ not only to examine the nature of Wilde’s revisions, but also the potential for technological tools to engage queerness in textual data. In doing so, it endeavors to answer a question that provokes the emerging field of Queer Digital Humanities, or Queer DH. As literary and electronic textual scholar Julia Flanders asks: ‘do we need to queer markup, or is markup already queerable?’ (2017). Flanders’s question considers the TEI’s place between two current approaches in Queer DH: the first approach wants to disrupt formal systems by imagining alternative ones, and the second, by contrast, maintains that queerness is built into computing and is inherent in computational logic. The first approach consists of speculative or critical making projects that problematize the constructed nature of technical objects. For example, Zach Blas and micha cárdenas propose a speculative codebase disrupts the expected functionality of computational programs. This project, transCoder, describes hypothetical computer programs such as the ‘destabilizationLoop’, which ‘breaks apart any process that acts as a continuously iterating power’ and ‘nonteleo()’, which ‘strips any program of a goal-oriented result’ (Blas and cárdenas: 2007–2012). Another project that probes the possibilities of queering digital tools is ‘Queer OS: A User’s Manual’, which describes how various components of an operating system might function within an ethos of queerness. For example, ‘Queer OS’ reconceives how a digital interface ‘might seek out self-modification as its ontological premise… transform[ing] both the user and the system’ (Barnett et al., 2016). Such work imagines technological systems and projects that ‘[do] not yet exist and may never come to exist [… do] not yet function and may never function’ (Barnett et al., 2016). The other side of the debate explores how current technological systems and tools already contain elements that encourage queer modes of analysis. For example, work by Jacob Gaboury explores how the ‘NULL value’ in computation signals a ‘refusal to cohere, to become legible’ as a built-in option in computational systems. Gaboury explains how the NULL value ‘corresponds with the epistemological condition of queerness as an excessive illegibility collapsed into an unwieldy frame, an aberrant third-ness within an otherwise normative system of relations’ (Gaboury, 2018). In another project, ‘The Queer History of Computing’, Gaboury exposes and interrogates the ways in which technology creates opportunities for resisting conscription within its systems. Gaboury asserts that ‘there exists a structuring logic to computational systems that, while nearly totalizing, does not account for all forms of knowledge, which excludes certain acts, behaviors, and modes of being’ (Gaboury, 2013: para. 13). According to Gaboury, it is from within this structuring logic that queerness finds the space to operate.
In an attempt to cut between these debates, this project first searches for a structural constraint within the TEI format, and then works through this constraint to analyze the homoerotic elements in Wilde’s manuscript revisions. As such, this project aligns with another that uses the TEI to destabilize our current understanding of Wilde’s textual and historical legacy. Jason A. Boyd’s Texting Wilde Project uses the TEI to mark up the biographical information, particularly references to persons, places, and events, in writings about Wilde’s life. Its goal is to reveal the historical discrepencies and inaccuracies across Wilde’s biography. Boyd points out that ‘Our knowledge of “Oscar Wilde” is not comprised of a corpus of pure and simple facts that allows us an unmediated apprehension of a real person separated from us by only time, but rather this knowledge is comprised of a densely complex and often contradictory accretion of texts’ (Boyd, 2014: para. 1).
Similar to Boyd, my project also uses the TEI to complicate the understanding of Wilde’s textual legacy. It identifies one major constraint of the TEI: that it works best with data that is discrete, rather than smooth data, like the homoeroticism obscured by Wilde’s pen. Here, I apply the rigid constraint of the TEI data structure towards marking up and analyzing this text’s homoeroticism, which I group into the general themes of ‘intimacy’, ‘beauty’, ‘passion’, and ‘fatality’, as well as the pen strokes that Wilde used to strike these elements from the text. The functionality of the TEI as a tool that bounds and labels data into discrete elements allows me to explore the indeterminate boundaries of these queer themes in the text. The strict nature of this tool compels literary researchers like myself to see how working with textual data in electronic formats will surface that which evades their grasp.
To inform my approach for handling homoerotic subject matter within digital contexts, I bring two fields, Textual Scholarship and Queer Historiography, into conversation. The debates within these fields allow me to carve out a methodology for digitizing what electronic editing scholar Jerome McGann calls our ‘textual inheritance’ (McGann, 2001: xi). Here, I identify a parallel debate between what I term the ‘restorative’ and ‘productive’ approaches to Textual Scholarship and Queer Historiography. In the field of Textual Scholarship, the restorative approach promotes editorial practices that increasingly delimit the role of the editor as a recoverer or preserver of texts, while the productive approach empowers the editor as an enabler of potential textual readings. The history of Textual Scholarship first tends toward the restorative approach, beginning with the work of Shakepearean scholar Ronald B. McKerrow, who maintains that the goal of scholarly editing is to preserve authorial intention. McKerrow’s influential model for ‘copy-text’ editing, which establishes the base-text for editing on an early witness that most closely resembles the author’s original intention, eventually gives way to Walter W. Greg’s approach that expands the purview of critics to more than a single witness. Subsequently, Fredson Bowers and Thomas Tanselle advance Greg’s work, proposing the ‘eclectic edition’ as the format that enables the editor to distil authorial intention from multiple sources.1 Tanselle, in particular, enshrines the role of the editor as the only figure capable of realizing the ‘work’ in its ideal form:
Those who believe that they can analyze a literary work without questioning the constitution of a particular written or oral text of it are behaving as if the work were directly accessible on paper or in sound waves … its medium is neither visual nor auditory. The medium of literature is the words (whether already existent or newly created) of a language; and arrangements of words according to the syntax of some language (along with such aids to their interpretation as pauses or punctuation) can exist in the mind, whether or not they are reported by voice or in writing. (Tanselle, 1989: 16–17)
Because the act of inscription involves physical tools that corrupt the writer’s pure ideas, the writer requires an editor whose distance from the creation of the work enables his objective evaluation of its intention. Tanselle’s prioritization of textual recovery exemplifies the restorative approach.
Toward the end of the 20th century, D. F. McKenzie’s ideas about ‘the sociology of texts’ challenge the claim that a single text can represent an ‘ideal’ version. According to McKenzie, the book is never one single object but stems from a number of human agencies and mechanical techniques that are historically situated: ‘Every society rewrites its past, every reader rewrites its texts, and if they have any continuing life at all, at some point every printer redesigns them’ (McKenzie, 1986: 25). Jerome McGann expands this sociological perspective into digital editing environments, where electronic formats create opportunities for presenting textual variation. McGann explains that textual criticism in print format is limited because a print text must conform to the linear and two-dimensional form of the codex: the same form as its object of study. Digital editions, by contrast, can be designed for complex, reflexive, and ongoing interactions between reader and text. McGann notes that his work on the digital Rossetti Archive brought him to repeatedly reconsider his earlier conception and goals, explaining that the archive ‘seemed more and more an instrument for imagining what we didn’t know’ (McGann, 2001: 82). McGann’s approach counters the traditional fidelity toward authorial intention with a drive to harness the potentiality of textual variation. The transformation of literary material into electronic format becomes a vehicle for a critical analytical method that McGann and Lisa Samuels call ‘deformative criticism’, which works by distorting, disordering, or re-assembling literary material in order to estrange the reader from their familiarity of the text. Continually subscribing the text to new configurations, this estrangement confronts the reader with new insights about its formal significance and meaning. For that reason, deformative criticism encourages a productive approach to editing.
Two competing approaches in the field of Queer Historiography parallel the ‘restorative’ and ‘productive’ approaches from Textual Scholarship. Susan McCabe defines ‘Queer Historicism’ as the ‘critical trend of locating “identifications” (rather than identity), modes of being and having, in historical contexts’ (McCabe, 2005: 120). In this field, critics often debate the extent to which they, in the present, can adequately describe queer identifications from the past. On the ‘restorative’ side, there is the Queer Historicist position advocated by scholars like David Halperin and Valerie Traub, who maintain that homosexuality is historically constructed; that ‘queerness’ means something different today than it did in the past, and that we can get at its meaning by employing a Foucauldian genealogical method that traces its meaning over time. Halperin, in particular, characterizes homosexual identity as a modern cultural production: ‘no single category of discourse or experience existed in the premodern and non-Western worlds that comprehended exactly the same range of same-sex sexual behaviors … that now fall within the capacious definitional boundaries of homosexuality’ (Halperin, 2000: 88). By contrast, the ‘unhistoricists’, including Jonathan Goldberg and Madhavi Menon, are wary of demarcating queer subjectivity across history in ways that imply progress. These scholars maintain that the attempt to define ‘queer’ would subscribe queerness to heteronormative teleology, which has the effect of normalizing (and therefore evacuating) queerness: ‘to produce queerness as an object of our scrutiny would mean the end of queering itself’ (1609, 1608). In response to this unhistoricist position, Valerie Traub maintains that ‘queer’ depends on historical specificity:
Queer’s free-floating, endlessly mobile, and infinitely subversive capacities may be strengths—allowing queer to accomplish strategic maneuvers that no other concept does—but its principled imprecision implies analytic limitations … if queer is intelligible only in relation to its social norms, and if the concept of normality itself is of relatively recent vintage (Locherie), then the relations between queer and the changing configurations of gender and sexuality need to be defined and redefined. (Traub, 2013: 33)
According to Traub, queerness requires historical specificity in order to be legible. If applied ahistorically, the term ‘queer’ would lose its descriptive value. This position aligns the historicists with the restorative impulse in Textual Scholarship, while the unhistoricist refusal to circumscribe such a definition recalls the productive approach.
Heather Love refocuses this methodological debate to emphasize the relationship between the critic and the object of study. Love makes the argument that, although the queer historian cannot validate the queerness of the past, the project of queer history must continue. Love explains that ‘Queer history has been an education in absence: the experience of social refusal and of the denigration of homosexual love has taught us the lessons of solitude and heartbreak’ (Love, 2009: 52).  Rather than attempt to ‘fix’ the past, however, Love offers the methodology of ‘feeling backward’, an accounting of ‘the social, psychic, and corporeal effects of homophobia’ (2). By ‘feeling backward’, Love is interested in exploring the way that subjects turn away or refuse the critic’s attempt to ‘redeem’ or ‘rescue’ them: she offers the myth of Orpheus and Eurydice, pointing out that Orpheus prefers to behold Eurydice in the darkness of the Underworld rather than in the sunlight.2 Although Orpheus intends to rescue her, bringing Eurydice into the light of day would transform her into something fully accessible and therefore less desirable. This is a crucial lesson for queer critics: ‘[Eurydice’s] specific attraction for queer subjects is an effect, I want to argue, of a historical experience of love as bound up with loss. To recognize Eurydice as desirable in her turn away is a way of identifying through that loss’ (Love, 2009: 51).
Plagued by the problem of what to do with the past, the critic’s impulse to ‘rescue’ queer figures evokes Tanselle’s aim to recover the ideal text in scholarly editing. Love, however, asserts that this rescue is impossible:
Such is the relation of the queer historian to the past: we cannot help wanting to save the figures from the past, but this mission is doomed to fail.  Such a rescue effort can only take place under the shadow of loss and in the name of loss; success would constitute failure. (Love, 2009: 51)
Perhaps this impossibility allows the critic to rethink how she might preserve the queer textual inheritance: accepting queerness as something that eludes containment compels her to explore how queerness escapes certain kinds of analyses. Love suggests ‘a mode of historiography that recognizes the inevitability of a “play of recognitions” but that also sees these recognitions not as consoling but as shattering’ (Love, 2009: 45). By ‘play of recognitions’, Love means the inevitable ‘search for roots and resemblances’ enacted by the critic when she encounters queer subject matter (45). I propose that this method of attending to elusive affects, without trying to transform them into something more palatable, can apply to digital contexts and toward productive ends. One may, borrowing from McGann and Samuel’s idea of deformance, reconceive textual editing as a formal experiment. The TEI can be used to explore how electronic editing tools impose new formal structures on queer subject matter. This allows one to take the attempt at recovery and, rather than aim for resolution, multiply the potential readings of textual elements. Using the TEI in this way allows researchers to direct ‘queer encoding’ practices toward enacting what Kadji Amin, Amber Jamilla Musser, and Roy Pérez describe as ‘queer form’, or ‘the range of formal, aesthetic, and sensuous strategies that make difference a little less knowable, visible, and digestible’ (2017: 235).
My work encoding Wilde’s revisions to the manuscript plays against the long-standing ‘recovery’ project about Wilde’s intentions as he revises Dorian Gray into the periodical and book versions. Textual scholars like Donald Lawler, Joseph Bristow and Nicolas Ruddick claim that Wilde’s revisions work toward the overall goal of aestheticizing the text. This project of aestheticization begins in the manuscript which is eventually published, in periodical form, in Lippincott’s Monthly Magazine on June 20, 1890.3 This first printing of ‘The Picture of Dorian Gray’, which spans 98 pages over 13 chapters, was widely criticized in the press for its seemingly ambiguous stance on an immoral protagonist. Bristow explains that ‘[Wilde’s] narrative struck the [reviewers] as a work that appeared “corrupt”, displayed “effeminate frivolity”, and dealt “with matters only fitted for the Criminal Investigation Department”’ (2000: xviii). Wilde spends the next several days defending his work in letters to the editors, entering into a public correspondence with them.4 A few months later, in the early spring of 1891, Wilde publishes a ‘Preface’ that makes such claims as ‘Those who find ugly meanings in beautiful things are corrupt without being charming. This is a fault’ and ‘To reveal art and conceal the artist is art’s aim’.5 Scholar Barbara Lecklie asserts that, by these complex and incisive statements, ‘Wilde’s strategy is to refocus on art and disparage the focus on the reader by saying that the reader is the one who makes a work immoral’ (2013: 173). Similarly, Lawler argues that ‘the “Preface” … hold[s] up aesthetic beauty and artistic effect as the only legitimate criteria of critical evaluation’ (1988: 16). The ‘Preface’ is included in the subsequent iteration of Dorian Gray, published in a book version by Ward, Lock & Company in April 1891. According to the editor of the Uncensored Edition of Dorian Gray, Victor Frankel, Wilde here makes significant deletions of passages referencing homosexuality, promiscuous or illicit heterosexuality, and ‘anything that smacked generally of decadence’ (2011: 47–48). Wilde also ‘heighten[s] Dorian’s monstrosity toward the novel’s conclusion’ to bring the story ‘to a moral conclusion that he thought would silence his critics’ (Frankel, 2011:30).
Created specifically for working with literary material, the TEI enables researchers
to describe, transcribe and edit print text or manuscripts in electronic format. The
TEI enables users to ‘mark up’ aspects of literary texts that they think
are important, such as structural elements (chapters, paragraphs, line breaks),
physical details about the text (revisions, illegible text) or conceptual elements
(persons, geographical locations). To mark up these elements, encoders use
‘tags’, such as <line>
to indicate a line
of text, <del>
to indicate deleted text, and
<person>
for a reference to a person. Below is an
image of Mary Shelley’s manuscript of Frankenstein; or, The Modern
Prometheus (1818) and its diplomatic transcription (see Figure 1). Beneath them is an excerpt of the
underlying TEI code, created by the Shelley-Godwin Archive.
<handShift medium=”pen” new=”#mws”/>
<line>Those events which materially influence our fu</line>
<line>ture destinies <del rend=”strikethrough”>are</del> often
<mod> <del rend=”strikethrough”>caused</del>
<del rend=”strikethrough”>by slight or</del>
<add hand=”#pbs” place=”superlinear”>derive thier origin from a</add>
</mod> tri </line>
<line>vial occurence <del rend=”strikethrough”>s</del>.
<mod spanTo=”#c56-0005.01”/> <del rend=”strikethrough” next=”#c56-0005.02”>Strange as the</del>
In the encoding, the <line>
tags indicate lines of text,
and <del>
tags indicate deleted text. Through this
level of detail, TEI facilitates deep and complex description of textual material
that facilitates scholarly research. This excerpt also includes a
<handShift>
tag and @hand
attribute, which indicate whose ‘hand’ is responsible for writing each
section of text: a valuable piece of information for a text co-edited by
Shelley’s husband, Percy Shelley.
TEI documents resemble an ordered hierarchy containing a nested tree structure, with one ‘root’ component and several ‘branches’, known as ‘nodes’. The TEI requires all elements in the text to be contained as discrete nodes within this bounded structure, and elements cannot overlap unless the inner element is fully nested within an outer element. Though the strict tagging structure of the TEI forces encoders to organize textual elements as discrete, ordered data, it also enables them to create their own labels for the elements. Perhaps the most useful aspect about the TEI is this customizability, which it inherits from its parent language, eXtensible Markup Language (XML). As an ‘extensible’ language, TEI users can create their own tags to describe the particular elements they wish to encode. The Women Writers Project (WWP), directed by Julia Flanders, adequately frames how TEI’s inherent extensibility can address textual ambiguity. According to the WWP:
Unlike many standardization efforts, the TEI … explicitly accommodat[es] variation and debate within its technical framework. The TEI Guidelines are designed to be both modular and customizable, so that specific projects can choose the relevant portions of the TEI and ignore the rest, and can also if necessary create extensions of the TEI language to describe facets of the text which the TEI does not yet address. (Flanders, 1999–2021)
Because TEI is built from a language that allows its users to build their own version of that language, there is potential for representing the elements necessary for a project by customizing these elements on a project-by-project basis.
As queer studies scholars may know, however, some textual elements will resist
containment within any kind of category. Accordingly, there are a number of projects
that explore the potential of the TEI for ‘queer encoding’, such as the
encoding of queer gender. The <person>
tag, which
describes persons referenced within a text, is limited to one value for gender,
which creates obstacles for scholars working to encode multiple or diverse sexual
identities. Pamela Caughie and Sabine Meyer, for example, use the the TEI to encode
Man Into Woman, the life narrative of Danish painter Lili Elbe,
who undertook one of the first gender affirming surgeries in 1930. The attempt to
mark up Elbe’s complex gender ontology brings Caughie and Meyer against this
structural limitation of the TEI:
[T]he deeper we got into mark-up, the more evident it became that the categories and hierarchies available to us were inadequate for our task… to identify a male subject who at times presents himself as masquerading as a woman, at others as being inhabited by one, and who eventually becomes a woman, in a life history narrated retrospectively from the perspective of Lili Elbe. (Caughie and Meyer, 2018: 231)
The TEI forces these scholars to consider the ways that computation works on a deeper level to reify gender as essential. In particular, the fixity that the TEI imposes upon Elbe as a queer subject brings out the ways that gender is situated and relational across this text.
Other scholars find advantage in the TEI’s strict data structure. While the TEI limits what constitutes a person—as an entity with one sex, for example—it also enables an approach toward personhood as multiple. Like Caughie and Meyer, Marion Thain also works to encode the diaries of a complex writing subject: the late 19th-century English poet, Michael Field. Michael Field is a pen name for the lesbian couple, Katharine Bradley and Edith Cooper, which signifies ‘the assumed names of two separate women, as well as appearing to signify one single male identity’ (Thain, 2016: 228). Fortunately for Thain, the TEI enables the encoding of distinct identities, which is central for understanding the queerness of the diaries:
[T]he proliferation and slipperiness of names is no mere childish caprice but a core part of the articulation of queer: an unhinging of ‘given’ or apparently predetermined identity through a strategy that articulates identity as constantly shifting, constructed, and performative. Text encoding can, in a simple but powerful way, help us explore and map this crucial strand of queer identity construction across the diary. (Thain, 2016: 233)
Thain’s approach harnesses the hierarchical nature of the TEI to list the
various references to each personage within the
<persName>
tag. This
<persName>
tag allows Thain to ‘render
searchable words not in the text but intimately tied to it. This is not a small
issue in a diary in which Katharine Bradley herself is referred to by more than 20
different names’ (Thain, 2016: 233). By
enabling Thain to encode multiple names for each writer of the text, the TEI data
structure enables Thain to manage the problem of queer identity in this text.
Why do Caughie and Meyer struggle to encode Elbe’s identity while Thain appears to succeed with Fields’? While a queerness like Fields’ might be delineated and contained, in Elbe’s there is a quality of blending which the markup, by its nature, means to separate and fix. As Flanders points out, markup is a tool for naming, bounding, and containment, and therefore registers information in distinct components (Flanders, 2017). Fields’ identity is multiple yet distinct: the diaries proffer ‘two different hands [that] record the experience of two clearly differentiated people’ (Thain, 2016: 229). By contrast, Elbe’s identity is plural, containing several identities whose relationship to each other is ambiguous or continually shifting within one entity. Elbe’s relation to gender is best described qualitatively, as one that alternatively ‘masquerades’ or ‘inhabits’ simultaneous gender ontologies (Caughie and Meyer, 2018: 231).
For Wilde’s text in particular, I created a customization that explores the
potential of semantic labelling against the demands for fixity and structure within
the TEI schema. My customization registers physical and conceptual changes to the
manuscript by creating two new attributes to mark the revisions. First, to mark the
physical traces of Wilde’s pen as he struck out portions of the text, the
custom attribute, ‘strokes’ (@strokes
in formal
TEI notation), registers the number of pen strokes through any given section of
text.6 Most often, Wilde uses one or two
strokes of his pen, although sometimes, the strokes are too heavy or thick to
enumerate. In those cases, I set the @strokes
attribute to
the value ‘inconclusive’. In addition to
@strokes
, the custom attribute
@implication
marks the general theme of revision from a
list of recurring themes, which include: ‘intimacy’,
‘beauty’, ‘passion’, and ‘fatality’, with the
additional values of ‘inconclusive’ or ‘illegible’.
In what follows, I detail how this customization registers the elisions of homoeroticism in the manuscript as Wilde prepared it for publication. The goal of this work is not to establish a formal method for marking queer elements, rather, it is to surface a resistance in the text: an indeterminacy that resists capture by the TEI data structure. Here, the difficulty is in engaging the boundedness of the TEI elements, which encapsulate data, with the indistinctiveness of the queerness of the text, which resist demarcation. The four themes of ‘intimacy’, ‘beauty’, ‘passion’, and ‘fatality’ constitute a spectrum of smooth information that threatens the confines of the TEI tags. To add another layer of ambiguity, the number of pen strokes also resists easy demarcation: they can be difficult to enumerate and their boundaries often fail to map with the themes. Therefore, in order to mark up this text, I impose decisions on the data.
The evocative opening scene, which consists of a lively dialogue between Basil Hallward and Lord Henry Wotton, sets the tone, reveals character dynamics, and lays out some of the conflict for the ensuing story. In these first few pages, Basil appears to be a sympathetic, sensitive, albeit slightly exasperated artist, who confides in his close friend Lord Henry the powerful influence that Dorian Gray has had upon his life and work. Lord Henry, by contrast, appears as an affable and witty gentleman aesthete, who counters Basil’s sincerity with offbeat observations and paradoxical aphorisms. From the revisions made to this opening scene, a few general patterns emerge. First, the revisions work to stifle the emotional tension and physical affection in the dialogue between Basil and Lord Henry, replacing it with a lighter or more neutral tone. Because these revisions generally shore up the friendship between Basil and Lord Henry, conveying fondness in their rapport, they are encoded according to the theme of ‘intimacy’. Second are the themes of ‘beauty’ and ‘passion’, which mostly concern revisions where Dorian is reformulated from a romantic object into an artistic subject for Basil’s painting. Third, and finally, is the theme of ‘fatality’, which emerges in moments where Basil struggles to explain the consuming and self-destructive effects of Dorian’s influence on his life.
On the theme of intimacy, Wilde’s pen slashes through evidence of physical contact between Basil, Lord Henry, and Dorian. This includes the following: ‘taking hold of his [Lord Henry’s] hand’ (9), Dorian’s ‘cheek just brushed my [Basil’s] cheek’ (20), Basil and Dorian ‘sit beside each other’ (22). Additionally, the dialogue between Basil and Lord Henry develops intimacy through their tone and subtle mannerisms, which facilitates Basil’s confession of his feelings for Dorian. In some cases, Wilde diminishes this intimacy in their conversation with the effect of mitigating the sense of foreboding that surrounds Basil’s attraction to Dorian. Here, Wilde replaces tense pauses with laughter or exchanges dramatic statements and descriptions with more playful ones. One such example occurs when Basil struggles to convey his reasoning for refusing to exhibit Dorian’s portrait:
‘The reason why I will not exhibit this picture, is that I am afraid that I have shown in it the secret of my own soul.’
Lord Henry hesitated for a moment. ‘And what is that?’ he asked, in a low voice. ‘I will tell you,’ said Hallward, and a look of pain came over his face. ‘Don’t if you would rather not,’ murmured his companion, looking at him. (9)
The revised version in the manuscript, incorporating the deletions and interlinear additions, reads:
‘The reason why I will not exhibit this picture, is that I am afraid that I have shown in it the secret of my own soul.’
Lord Henry laughed. ‘And what is that?’ he asked. ‘I will tell you,’ said Hallward, and an expression of perplexity came over his face. ‘I am all expectation Basil,’ murmured his companion, looking at him. (9)
Here, several changes mitigate the emotions of the scene. First, rather than ‘hesitate’, Lord Henry ‘laugh[s]’, and he no longer speaks ‘in a low voice’. The effect is to overwrite a previously intimate moment with levity. Basil also exchanges his facial expression from one of agony to confusion when ‘a look of pain’ transforms into ‘an expression of perplexity’. Lastly, Lord Henry, rather than sympathizing with Basil or excusing his obligation to explain himself, instead encourages him to speak: ‘I am all expectation, Basil’. Together, these changes work to obscure Basil’s internal suffering with the effect of lightening the mood of the scene.
Another example similarly tempers the intense, emotional energy while also mitigating
a sense of anxiety or foreboding. It occurs on the following page, where Basil is
on
the verge of revealing the reasons behind his attraction to Dorian. The original
dialogue proceeds: ‘Lord Henry felt as if he could hear Basil Hallward’s
heart beating, and he heard his own breath, with a sense almost of fear. “Yes.
There is very little to tell you,” whispered Hallward, “and I am afraid
you will be disappointed. Two months ago…”’ (10). The
manuscript’s revised version reads: ‘Lord Henry felt as if he could hear
Basil Hallward’s heart beating, and he wondered what was coming. “Yes.
There is very little to tell you,” whispered Hallward rather bitterly,
‘and I dare say you will be disappointed. Two months ago…”’
(10). Here, rather than draw attention to Lord Henry’s breathing, Wilde
mentions Lord Henry’s ‘wonder’ about Basil’s pending
explanation, which shifts Lord Henry’s sense of anticipation from fear to
curiosity. Wilde also makes slight changes to Basil’s delivery: in the revised
version, Basil speaks ‘rather bitterly’ and uses the expression ‘I
dare say’ rather than ‘I am afraid’. Both changes diminish the
confessional tone that originally precedes Basil’s revelation about Dorian
Gray. In this change, and in the aforementioned passage, the close rapport, the
‘intimacy’, between Basil and Lord Henry enables Basil’s
confession about the self-consuming qualities of his feelings for Dorian, which
suggests a connection to the theme of ‘fatality’. The data structure of
the TEI, however, fails to capture this complicated dynamic because the
@implication
attribute is limited to one value.
Therefore, the encoder must choose one theme per item of revision, either
‘intimacy’ or ‘fatality’.
Throughout this chapter, Wilde often swaps out words with the effect of diluting or diverting their original connotation. He focuses this type of revision on Basil’s dialogue, when Basil speaks about his passionate attachment to Dorian and the effect of Dorian’s beauty upon his art. Here, Wilde trades expressive nouns with words that convey relatively weaker or more generalized ideas. For example, in the sentence ‘Every portrait that is painted with passion is a portrait of the artist, not of the sitter’, Wilde replaces ‘passion’ with ‘feeling’ in the manuscript (9), exchanging the romantic connotation of ‘passion’ with the more neutral one of ‘feeling’. Additionally, on the theme of ‘passion’, Wilde substitutes words and phrases which connote a strong sense of romantic passion for ones that instead suggest an aesthetic interest. One line, prior to revision, reads: ‘I knew that I had … come across someone whose mere personality was so fascinating that it would be Lord over my life, my soul, my art itself’ (11).  Here, Wilde swaps out ‘life’ for ‘nature’, with the effect of subscribing Dorian’s influence to his ‘nature’, that is, part of his personality or behavior, rather than encompassing his ‘life’. Wilde also replaces ‘be Lord over’ with ‘absorb’, which maintains Basil’s sense of submission to an external force without the patriarchal designation in ‘Lord’. These changes, which are encoded under the theme of ‘passion’, diffuse a consuming quality in Basil’s attraction into a sensitivity to Dorian’s aesthetic influence. Like the revisions to the theme of ‘intimacy’, the subtle changes of word choice in this section also begin to gesture to the theme of fatality, which fully develops over the next several pages.
In addition to words associated with ‘passion’, Wilde often replaces the word ‘beauty’ in Basil’s references to Dorian. In doing so, Wilde neutralizes the power of Dorian’s physical allure.  The replacement of ‘beauty’ with ‘personality’ allows Basil to avoid mentioning Dorian’s physical appearance, and the addition of ‘strangely’ serves to mystify Dorian’s influence over Basil. Throughout the rest of chapter, Wilde makes several changes that similarly dilute Dorian’s powerful appearance: he replaces ‘beauty’ with ‘good looks’ and then with ‘face’ two separate times (6, 18). Finally, in reference to Dorian Gray, the word ‘Narcissus’ is replaced with ‘man’ (13). Like the previous changes on the theme of ‘passion’, the changes in words associated with ‘beauty’ shift the original connotation. Here, the decision to replace ‘beauty’ with references to ‘face’ or ‘good looks’ maintains the emphasis on the physical while muting the suggestive power of ‘beauty’ in the abstract. In doing so, connotations about the ideal, the charming, and the alluring, which usually accompany descriptions of beauty, are diffused into physical description. This evacuates Dorian’s mysterious allure and diminishes the overwhelming influence that he holds over Basil.
Removing associations with beauty and passion is part of Wilde’s larger effort of aestheticizing Dorian, transforming him from an erotic object into an aesthetic object. At the end of the first chapter, Basil implores Lord Henry to refrain from influencing the impressionable youth. The original version reads:
‘Don’t take away from me the one person that makes life lovely for me. Mind, Harry, I trust you.’ He spoke very slowly, and the words seemed wrung out of him, almost against his will.
‘I don’t suppose I shall care for him, and I am quite sure he won’t care for me,’ replied Lord Henry smiling, and he took Hallward by the arm, and almost led him into the house. (27–28)
Lord Henry’s assurance that neither he nor Dorian shall ‘care for’ each other characterizes Basil’s passionate feelings for Dorian as a kind of general possessiveness. However, the source of Basil’s anxiety is specified with the next revision:
‘Don’t take away from me the one person that makes life absolutely lovely to me, and that gives my art whatever wonder or charm it possesses. Mind. Harry, I trust you.’ He spoke very slowly, and the words seemed wrung out of him almost against his will.
‘What nonsense you talk,’ said Lord Henry smiling, and, taking Hallward by the arm, he almost led him to the house. (27, 27B)
In this revision, Basil attributes an aesthetic value to Dorian, asserting Dorian’s importance for his art, giving it ‘whatever wonder or charm it possesses’. Lord Henry’s response moves from reassurance to dismissal, rejecting Basil’s anxiety as ‘nonsense’ and ending the scene on a slightly humorous note. Across these changes, Wilde refocuses Basil’s jealous passion into an anxiety about losing Dorian as an artistic subject. Additionally, the shift from sincere reassurance to light-hearted repartee in Lord Henry’s response evacuates the strong emotional tone of the scene, replacing it with friendly banter. The effect is to divert Basil’s passion for Dorian toward aesthetic appreciation.
Wilde’s efforts in redirecting Basil’s passion toward artistic ends is inextricable from the attempts to soften Basil’s intense and consuming devotion to Dorian, which emerges in references to Basil’s troubled state of mind. One example occurs when Basil recounts his first time meeting Dorian: ‘I had a strange feeling that Fate had in store for me exquisite joys and exquisite sorrows. I knew that if I spoke to him, I would never leave him till either he or I were dead. I grew afraid, and turned to quit the room’ (12). Here, Basil’s passion swells with an intense, life-threatening quality that Wilde’s pen works to mitigate by removing the association with death. He crosses through ‘never leave him till either he or I were dead’ and adds ‘become absolutely devoted to him, and that I ought not to speak to him’. Wilde again tempers this self-consuming quality of Basil’s devotion when he changes the phrase ‘I could not live if I did not see him every day’ to ‘I couldn’t be happy if I didn’t see him every day’ (17). By shifting the focus from Basil’s ‘life’ to his happiness, Wilde dilutes the profound peril that Basil’s passion has generated.
The TEI data structure reinforces the difficulty of disambiguating the revisions within the themes of passion and fatality. In the phrase discussed above, ‘look of pain’ is revised to ‘an expression of perplexity’ (9).7 Working with this revision in the TEI presents two points of contention (see Figure 2). First, in categorizing the theme, does the phrase ‘look of pain’ express passion or fatality? On the one hand, ‘pain’ denotes a strong, passionate feeling; on the other, Basil often draws on pain in his references to the fatalistic qualities about his attraction to Dorian, as in the following quote which was deleted: ‘I feel, Harry, that I have given away my whole soul to someone seems to take a real delight in giving me pain’ (23). The difficulty of disambiguating the theme is mirrored by the strokes of Wilde’s pen, which vary even across the same phrase: while the word ‘look’ is struck so heavily that the number of strokes is inconclusive, the word ‘pain’ contains a single stroke. With the TEI, it is impossible to mark the variations in strokes without separating the single revision into two instances, which would break up the integrity of the phrase. Therefore, it is marked with the value ‘inconclusive’. The ambiguity in the number of strokes also deepens when considering the semantics of the revision: the heavier strokes are focused on a revision (‘look’ to ‘expression’) that carries less semantic weight than the single stroke (‘pain’ to ‘perplexity’). In this case, the labelling fails to register even suggest the ways that different components are interrelated. The reasoning behind the relationship between the themes and the strokes remains recalcitrant.
My final example concerns a longer passage that was heavily revised in the manuscript.8 The treatment of this passage crystallizes the various patterns of revision seen so far—diminishing signs of intimacy, passion, and references to Basil’s fatalism. The passage in the manuscript bears quoting in full. Prior to any revisions, it reads:
‘You remember that landscape of mine… It is one of the best things I have ever done. And why is it so? Because, while I was painting it, Dorian Gray sat beside me, and as he leaned across to look at it, his cheek just brushed my cheek. The world becomes young to me when I hold his hand, as when I see him, the centuries yield up all their secrets!’
‘Basil, this is [illegible] you must not talk [illegible] [illegible] his power, [indecipherable] to make yourself the [illegible] slave! It is worse than wicked, it is silly.
Hallward got up from the seat, and walked up and down the garden. A curious smile curled his lips. He seemed like a man in a dream. After some time he came back. ‘You don’t understand, Harry…’ he said. ‘Dorian Gray is merely to me a motive in art. He is never more present in my work then when no image of him is there. He is simply a suggestion, as I have said, of a new manner. I see him in the curves of certain lines, in the loveliness and subtleties of certain colours. That is all.’
‘Then why won’t you exhibit his picture?’
‘Because I have put into it the romance of which I have never dared to speak to him. He knows nothing about it, but the world might guess it, where there is merely love, they would see something evil, where there is spectacular passion, they would suggest something vile.’ (20–21)
The TEI surfaces Wilde’s layers of revision in this passage (see Figures 3 and 4). In the first paragraph, Wilde eliminates a span of text from ‘and as he leaned’ to ‘secrets!’. Within this span, Wilde makes additional changes, adding text such as ‘hair just touched my hand’. Due to its physical nature, this particular phrase is marked as ‘intimacy’ in the TEI, while the longer section is enclosed by the label of ‘passion’, which denotes the nature of the other revisions within the same sentence, like ‘The world becomes young to me when I hold his hand’. Here, the TEI enables a layered approach to markup where one element can be nested within another.
While the first paragraph is legible, the next one, by contrast, is almost completely
blotted out. It consists of Lord Henry’s condemnatory and jealous
protestations: ‘his power’, ‘to make yourself the …
slave!’ and ‘I hate Dorian Gray’. Here, Wilde obscures the
fatalistic connotations of Basil’s passion, which exasperate Lord Henry.
Accordingly, the @implication
is marked as
‘fatality’ and the @strokes
are marked as
‘inconclusive’.
Most of the third paragraph is preserved, presumably for how it furthers Dorian’s aestheticization. Here, Basil elaborates upon Dorian’s aesthetic influence, which inspires his apprehension of the natural world. In the following paragraph, however, Wilde again obscures much of language, which revolves around the themes of passion and fatality. On the theme of fatality, the small adjustment of ‘would’ to ‘might’ eliminates a sense of inevitability about Basil’s feelings for Dorian. On the theme of passion, the revelatory line: ‘where there is merely love, they would see something evil, where there is spectacular passion, they would suggest something vile’ is completely struck out. This statement clarifies Dorian’s importance for Basil as the source of a powerful allure that suffuses Basil’s art with beauty. Notably, the strokes over the phrase ‘suggest something vile’ are doubled, which cannot be encoded in the TEI without separating the revision into two instances. As with the deletion of ‘look of pain’ (9), marking each element here with precision would require separating into distinct entities what is in fact one act of revision that contains plural implications. It would involve resolving Wilde’s perhaps indeterminate motives into a single intention.
On one level, the TEI encoding reinforces the claim by Lawlor, Frankel, and Bristow that Wilde diminishes the homoerotic elements by transforming Dorian from an erotic into an aesthetic object. This goal is achieved in three ways: first, by easing the tension surrounding his dialogue with Lord Henry; second, by emphasizing Dorian as an ideal subject for art; and finally, by removing the destructive connotations of Basil’s attachment to Dorian. On a deeper level, however, the existing textual scholarship has yet to contend with the complex ways in which Wilde’s intentionality is distributed among the revisions. To resolve some of the difficulty with encoding this text, one might employ more precise qualitative markers such as ‘tension’ in addition to ‘intimacy’, or ‘ardor’ and ‘devotion’, in addition to ‘passion’, for example. But creating more tags would dilute the analytical utility of the TEI encoding, which is meant not meant to be exhaustive. In this project, the TEI reveals that the themes of intimacy, beauty, passion, and fatality operate in intransigent or inscrutable ways: at times they are plural, co-existing within a single line of text; more often, they are inextricable, with one enabling the other, like intimacy and passion which enable fatality; at other times, they enfold one within the other, encompassing a plurality of intentions. The TEI, which requires strict disambiguation, surfaces how these themes work together in ways that cannot be captured by its data structure.
As Heather Love points out, queerness will be ‘always bound up with loss’ and the attempt to ‘rescue’ or ‘recover’ it will only lead to inevitable failure (2009: 51). The TEI enables an approach toward editing in this text that complicates, rather than resolves, queerness. By encouraging encoders to impose a level of fixity on the text, the TEI allows them to discover exactly where queerness eludes containment. This computational constraint of the TEI is an enabling one: by surfacing moments of failed disambiguation, the TEI reinforces the encoder as the one who ascribes semantic value to Wilde’s revisions. This failed disambiguation is also productive: the practice of pinning something down only to realize that such intelligibility is impossible. The TEI has been productive precisely because it requires the encoder to construct labels for textual elements which, cannot be fully recovered. Accordingly, this practice in ‘queer encoding’ does not attempt to resolve the question of Wilde’s revisions but tags the homoerotic elements in such a way that allows them to retain some of their elusiveness. One may examine the formalizations produced by this TEI schema not for what it reveals about Wilde’s intentions, but for how it releases potential readings of the history of his composition, in other words, to mark and visualize its queer form: the elusive affects, repressed desires, and other coded elements of queerness within this text. The TEI confronts one with precisely that which escapes existing structures for knowing queerness, in order to suggest, without fully grasping, its ever-shifting permutations.
[2] As the condition of rescuing his lover Eurydice from Hades, Orpheus must not look at her until they exit the Underworld and re-emerge into the sunlight. Unable to restrain himself, Orpheus turns to gaze at Eurydice as they are about to pass through the threshold. In this glimpse he manages to catch of his lover, she is already shrinking away into the darkness where she will be forever imprisoned.
[3] See Frankel, pp. 40–54, for a more complete accounting of the role of John Marshall Stoddart (Wilde’s publisher) in preparing the typescript for publication.
[4] See Wilde, O and M P Gillespie, pp. 358–374, for a selected list of full-length reviews from The Scots Observer, The St James Gazette and the Daily Chronicle, and Wilde’s responses.
[7] See Wilde, p. 9. Manuscript image available here: https://www.themorgan.org/collection/oscar-wilde/the-picture-of-dorian-gray/11.
[8] See Wilde, p. 20. Manuscript image avaible here: https://www.themorgan.org/collection/oscar-wilde/the-picture-of-dorian-gray/22; and page 21: https://www.themorgan.org/collection/oscar-wilde/the-picture-of-dorian-gray/23.


|
blmc_robots
|
Simple class that defines a polynome of order ORDER. More...
#include <polynome.hpp>
Public Member Functions | |
| TimePolynome () | |
| ~TimePolynome () | |
| double | compute (double t) |
| TimePolynome<ORDER> definitions. More... | |
| double | compute_derivative (double t) |
| double | compute_sec_derivative (double t) |
| double | get_final_time () const |
| double | get_init_pose () const |
| double | get_init_speed () const |
| double | get_init_acc () const |
| double | get_final_pose () const |
| double | get_final_speed () const |
| double | get_final_acc () const |
| void | set_parameters (double final_time, double init_pose, double init_speed, double final_pose) |
| Computes a polynome trajectory according to the following constraints:
. More... | |
| template<> | |
| void | set_parameters (double final_time, double init_pose, double init_speed, double final_pose) |
| Public Member Functions inherited from blmc_robots::Polynome< ORDER > | |
| Polynome () | |
| Polynome<ORDER> definitions. More... | |
| ~Polynome () | |
| double | compute (double x) |
| double | compute_derivative (double x) |
| double | compute_sec_derivative (double x) |
| void | get_coefficients (Coefficients &coefficients) const |
| void | set_coefficients (const Coefficients &coefficients) |
| int | degree () |
| void | print () const |
Protected Attributes | |
| double | final_time_ |
| store the inputs for later access | |
| double | init_pose_ |
| store the inputs for later access | |
| double | init_speed_ |
| store the inputs for later access | |
| double | init_acc_ |
| store the inputs for later access | |
| double | final_pose_ |
| store the inputs for later access | |
| double | final_speed_ |
| store the inputs for later access | |
| double | final_acc_ |
| store the inputs for later access | |
| Protected Attributes inherited from blmc_robots::Polynome< ORDER > | |
| std::array< double, ORDER+1 > | coefficients_ |
Simple class that defines a polynome of order ORDER.
With being the time in any units. It provide simple methods to compute safely , , and
| ORDER |
|
inline |
Constructor
|
inline |
Destructor
| double blmc_robots::TimePolynome< ORDER >::compute | ( | double | t | ) |
TimePolynome<ORDER> definitions.
Compute the value.
| double blmc_robots::TimePolynome< ORDER >::compute_derivative | ( | double | t | ) |
Compute the value of the derivative.
| double blmc_robots::TimePolynome< ORDER >::compute_sec_derivative | ( | double | t | ) |
Compute the value of the second derivative.
| void blmc_robots::TimePolynome< ORDER >::set_parameters | ( | double | final_time, |
| double | init_pose, | ||
| double | init_speed, | ||
| double | final_pose | ||
| ) |
Computes a polynome trajectory according to the following constraints:
.
| final_time | is used in the constraints. |
| init_pose | is used in the constraints. |
| init_speed | is used in the constraints. |
| final_pose | is used in the constraints. |


Overview
The society runs regular events for the benefits of students and the community as all are welcome and free to attend. We have three standard types of events
Teach Me How To
An event where a student or guest speaker teaches about a topic they know. Past events have included Linux, Unity, Ruby, etc.Challenge Night
A continuation of the previous Teach Me How To where students collaboratively code using the skills taught.Help Session
An event for students to get together and work on homework or discuss/rubber duck problems they are experiencing.Special Event
A special event that the society runs.Resources
A collection of links found useful by members of the society. Something missing? Something out of date? Create an issue! Or better yet a pull request!-
Society Links
Cheatsheets
Free Resources & Tools
Learning Resources
Online Development Environments
Online Development Playgrounds
Awesome Things
Society Links
- Email -<EMAIL_ADDRESS>- Google Calendar - Sync
- Google Drive
- GitHub Organization
- Facebook Group
Cheatsheets
Free Resources & Tools
- MSDNAA - Microsoft tools & OS (Visaul Studio, Windows 7, etc.)
- GitHub Student Developer Pack
Learning Resources
- General
- Unity
- Unix
- Python
Online Development Environments
Online Development Playgrounds
- Tutorials Point - Coding Ground
- JS Bin
- JS Fiddle
- Code Pen
- Teh Playground! (PHP)
- Regex 101
- Pythex (Python Regex)
- Dillinger (Markdown Editor)


15-418 Project
Home
Summary
Background
The Challenge
Resources
Goals and Deliverables
Platform Choice
Schedule
Demo
(current)


So I’ve just started working with Google Apps Script.
Google Apps Script is a Javascript based programming language that seemlessly links to google docs.
I’m creating a tool to update a googlesheet based on information entered into other googlesheets - ideally it’ll save some time as before the updates were done manually every day.
I’m relatively new to Javascript and I am brand new to Google Apps Script. Thankfully there’s plenty of help online. For general Javascript help check out the following:
- w3schools provides a huge amount of training materials
- StackOverflow never fails to disappoint to answer every weird and wonderful question
And Google has written some comprehensive documentation here. You find that Google has created objects and methods for all the Google linked tools (docs, googlesheets, calendar, mail, etc.).
I’ve created a DEMO workbook here. Here is a quick gif of it in action:
Here are a few useful pieces of code I picked up during my work:
// Open a workbook by URL
var workbook = SpreadsheetApp.getActive();
// Open the attached workbook
var workbook = SpreadsheetApp.openByUrl();
// Get a sheet by name
var sheet = workbook.getSheetByName("Sheet1");
// Get values from sheet
var values = sheet.getRange(row, column, numRows, numColumns);
// Change font colour of values in sheet
sheet.getRange(row, column, numRows, numColumns).setFontColor(colour);
The main quirk to working with Google Apps Scripts is that there isn’t a terminal. Instead you can use the Logger.log("string")
function to print to logs, which you can view by selecting “View” and then “logs” - this is surprisingly slow!! 😕 The other solution, which I use in my demo above, is to print to a google document. Here, I print messages to a sheet within a googlesheets workbook:
function printToLog(logSheet, string, colour="black") {
// Get the number of rows in the log sheet
var nRows = logSheet.getLastRow();
// Get the current time
var timeStamp = new Date();
// Pring to log
logSheet.getRange(nRows+1, 1).setValue(timeStamp);
logSheet.getRange(nRows+1, 2).setValue(string).setFontColor(colour);
}
I’d recommend taking a look at my demo workbook, it is amazing how easy it is to create menus and attach functions! Also, because Google Apps Scripts is based on Javascript there are no limits to what you can do!!
Note that the demo is read only, so you’ll need to make a cpoy before you can play around with it.
Lastly, get into the Google documentation, it is easy to search and well presented with great examples of how each function works. Enjoy! 😀


This page is the simplest of balances in table form.
Account ID
Account name
Account type
Balance
1
My first account
Current account
£-124.86
2
My mortgage
Mortgage
￡-198,765.43
3
My first saver
Savings account
£1,234.56


Hello! My name is David. I'm a full-stack web developer. That means I build all the parts of web sites and web apps. For example, this web site has an API for getting it's content and a CMS for editing from anywhere. If you'd like to take a deeper dive into how this website ticks, It's all open source.
If you want to talk to me, you can email me here or iMessage me.


Toggle navigation
Help
First Item
Second Item
Third Item
My Booking
INDIA
WIFI
GYM & YOGA
POOL
SPA
KITCHEN
SEARCH
Search By City
MG Road
Bangalore
Connaught Place
Delhi
Malabar Hill
Mumbai
Connaught Place
Delhi
Malabar Hill
Mumbai
Feature Property
Get our newsletter and stay current on rental deals and specials.
Subscribe
Connect with us :
© 2019 rooms - All rights reserved


Home
About Me
Portfolio
Contact Me
Software Engineer • Web & Mobile App Developer
Welcome! Check out my 'About Me' for my resume and my 'Portfolio' for a look at my current and past projects.
Looking to join an innovative team as a full-time software engineer. Experienced in Java, Python, Node.js, and Swift.
Website design created using templates from Bootstrap and W3Schools.


Exception in thread "main" java.util.NoSuchElementException
Post by: Tor Ludgivsen, Greenhorn
on Dec 15, 2012 15:52:49
Hello, im new to this forum. And pretty new to java programming. I made this note system, so i have control over my notes at school. It will take in a name (philosophname) and store it in a .txt file named navn.txt and it also have a .txt file where i put in the notes in notat.txt.
my problem now is, when i add a new name i get this error. the name is stored in the file. and i can see the new name but i want to not get this error, so that i dont have to restart the program.
Post by: Avery Torres, Greenhorn
on Dec 15, 2012 18:16:24
Take out all of your close System.in statements, ie "sc.close()" and "f.close()". Should work like a charm from there, also you might want to type check so that there is a catch in the menu if the user inputs a noninteger so that it doesn't just crash.
Post by: Tor Ludgivsen, Greenhorn
on Dec 16, 2012 12:43:57
omg, that easy o.O exactly why did that make that kind of error?
and btw, i will need the "f.close()" orelse it wont store into the .txt file + i have learned on school always to close the file you write to when you open it and finished with it.
but a new "problem" happend now. i do not get the error, but when i write new name i have to Exit(opt 10 in meny) to update the allname list.
yes tnx, will work with the checks on the meny.
Post by: Avery Torres, Greenhorn
on Dec 16, 2012 13:43:17
I believe the whole problem is coming from wanting to read and write the same file without having ever saved it. There are many ways to get around this one may be using a RandomAccessFile.
Post by: Tor Ludgivsen, Greenhorn
on Dec 16, 2012 17:09:05
exactly how do i split the context?
name;lastname;name-lastname
with this randomaccessfile is it the same way to split the context?
because later on, the note text will look like
note;key
here is the note bla bla bla;name-lastname
All times above are in ranch (not your local) time.
The current ranch time is Dec 13, 2013 16:37:24.


{#-
Hinweise zum Backen...
-#}
{%- if child.oven is defined and child.oven != "" and child.oven.blocks or
child.oven_type is defined and child.oven_type != "" or
child.oven_time is defined and child.oven_time != "" -%}
{{- '\n ' -}}
{{- '\n ' -}}
{{- '\n ' -}}
Backhinweise
{{- '\n ' -}}
{%- if child.oven is defined and child.oven != "" and child.oven.blocks is defined and child.oven.blocks != "" -%}
{% if child.oven.blocks is defined and child.oven.blocks != [] -%}
{%- for ovn in child.oven.blocks -%}
{%- if ovn.amount is defined and ovn.amount != "" -%}
{{- '\n ' -}}


{{employeeName}}
{{employeeEmail}}
{{employeePhone}}
{{employeeAltPhone}}
{{National_Id}}
{{KRA_Pin}}
{{jobId}}
{{jobGroup}}
{{requestAs}}
{{requestOn}}
{{updateOn}}


A report from the course development for the web
S01
I have prior experience and feel experienced in GIT. I have been hosting a git-server since 2,5years and been the main code administrator during past projects. Of course, I do not know everything, but I have enough knowledge to find solutions to the more advanced problems when they arise.
GitHub:
Yes, some experience. I also have some e experience using GitLab. Haven't used either of them that much due to
I have been using my own git-server.
Markdown:
I have only limited experience of markdown. I get around and know the basics but I do not know it by heart
GitHub pages:
I have some previous experience with GitHub pages but only limited of the same reason as stated above.
Creating web pages:
I do have some previous experience in creating websites. Both in pure HTML/Flash and in HTML/CSS/JS(React/TypeScript).
As stated before, I have some knowledge but it's just the basics.
I would describe my previous experience in web development as overall limited. I get things done but it takes some time and research due to lack of experience and knowledge. Why haven't I developed that much for web? The dynamic typing in JS is confusing for me that normally use C/C++ and Android/Java. And when working with UX/UI I often find myself lacking ideas for design.
Today I learned about some new frameworks and techniques used for web-development. As I said before, it’s a jungle out there. And there is always something new...
S02
A short description of what makes a web page: HTML gives the page its structure, what goes where, where resources can be found etc. CSS fine-tunes how different elements of the page is visualised, interacts with other element and how they should respond to triggered events. JavaScript provides dynamic to the page. Fetching of remote data, filtering data and calculations are some common implementations.
I do have prior experience with HTML, JS and CSS but have lately used React.JS and Typescript to develop websites. On top of that I haven't really made any attempt to deep-dive into it. Web-development have always been an anxiety for me. I really do still experience confusion when it comes to web-development. It seems unstructured when compared to "normal" development.
During this section I have been playing and debugging with CSS, both inline and in stylesheet. This work with CSS and JS has had the consequence that I have learned some new techniques to implement the desired effect on components.
A short description of browser - HTTP - web server interaction:
A user request a web page via a browser. The browser connects to the web server via a HTTP GET. The web server
looks
for the resource specified in the GET from the browser. If found the web server responds to the browser with
the requested data and the return code 200.
Upon receiving the data (string of html) from web server the browser searches the received html for external
resources referenced.
The browser performs request for these resources and when all resources are locally(there are exceptions to
this of course) the page will be showed from the user
S03
Target grade: 5
As said before I consider my skills in JS to be basic at best. When it comes to actual code JS is ok but when it comes to the finer details like how data is stored, referenced and handled I tend to use the C/C++/java approach and I think there's a better way in JS that I need to find and learn.
In all these exercises and for the course in general I aim for grade 5. I do acknowledge that my
skill/experience in design is poor but I hope that my technical skill will be enough to reach my goal.
For this section of the course I have used my own web-server (Bitnami/Apache/Tomcat) for testing of the fetch
function. Me and a classmate have been using this server earlier for testing in a react-project that we have
as a pet project. On this server I have implement a CORS-filter, so we don't face that problem when testing
scripts. After I verified the functionality of fetching data from a web-api I switched to get the data from
GitHub instead. For convenience.
As for the js/CSS/html during this section I have really tried to challenge myself. To sit with the code and
make it work. Not googling away for solutions at the slightest problem but try and try and read and try until
a working solution is produced. By me. I wanted to test if I could "crack" the JavaScript enigma I was so
afraid of. And I must say it worked.
A note on my solution: When I was converting my js for the plane (moving object) to object I thought was
supposed to create a class definition. It was fun and result was ok. My friend spoke to you 31st of Jan of my
solution and according to him you said it was fine. I do know how to work with JavaScript object-literals.
I have appended an additional script for the plane using only an object-literal (work/s03/js/plane.js). Not as fancy as the first one I did thou...
TIL: For the first time I feel a little bit more comfortable with JS. Working with object and class definition
gave me some insight into some dom-features
and some pitfalls. For ex. the windows.setInterval() runs a function at set interval. Problem is that function
seem to be invoked on a temporary obj.
Due to this I had to rewrite the code to get a handle on the object I wanted to handle. There's probably a more
correct way of doing this but now it works. I will continue try different solutions.
As for CSS I feel more confused than ever. There seem to be no structure or standardizing structure regarding
functions available. I feel it's just trial and error to get the desired design. Sometime using only CSS and
sometime a combination of html and CSS. I do get the design I want thou.
During this section I have become much better at using the debugging tools available in my browser. To spot
errors, refine code and to understand the Dom's inner workings
Grade fulfilment
-
Grade 3: Requirements fulfilled. A plane is used instead of a duck. The plane will make a turn when clicked. The plane will also seek to locate itself inside viewport
-
Grade 4: Requirements fulfilled. Button to hide/show plane added and flag page
-
Grade 5: Requirements fulfilled. Plane has been re-implemented as an object and flag page has been upgraded with CSS with smooth transitions
S04
Target grade: 5
I have previously used NPM and Node. Mostly NPM because I have worked with React.JS which is handled by NPM.
My aim when developing is to have a purpose when I use libraries and frameworks. I see advantages with express. It's easy to quickly produce a dynamic site. I am sure there is loads more advantages but as a novice I do not know about them yet. Having said this, I will try to avoid these kinds of supporting frameworks for now. Why? Because I want to learn the foundations well before taking shortcuts. I believe this will make me a more skilled developer in the end.
During this course I have really come to accept and like the JS, a language that used to make me anxious. I am
truly happy that I pressed on in the earlier tasks to push me to learn it. I do however like c/c++ more :-)
As for Node and Express I see their uses but I leave it at that for now
My approach was to make grade 3, then 4 and last 5. When done I try to enhance and tidy the code and design. In all these assignments I aim for grade 5. I feel that it is challenging to aim at this grade. It takes time to solve the grade 4 and 5 tasks but I motivate myself with the knowledge that for every line of code I write I learn a little bit more. And that makes it worth all the long hours.
My main take-aways from this course section is the routing, data-handling and processing in express. It was clean and pretty straight forward.
Grade fulfilment
-
Grade 3: Requirements fulfilled.
-
Grade 4: Requirements fulfilled.
-
Grade 5: Requirements fulfilled.
S05
Target grade: 5
PHP as a language is similar to use as JSP. The code structure is similar, and I had the same challenges in php as
in JSP. JSP is, however, "closer to home" for me and I would probably use JSP over PHP if I had to choose
between them. It is server-side and all dynamics is rendered server-side. As a
consequence all user-initiated page dynamics that can't be solved with CSS has to be sent to server to rerender
the page. It is rather provocative to sit and bounce data on the server to solve things that can be done locally
if I were permitted to use JS. But that in itself is a nice challenge.
The feeling I get when working with PHP is that it is an older language like Fortran. This is however not correct.
The language was born in 1994. I read a little bit of how PHP came to be, and I suspect that the
non-standardized evolution in early PHP may tint my experience. The over the top delimiter tags, maybe?
I cannot put my finger on what factors gives me this feeling of "old" but it is there.
My aim during this section was to get a 5. My strategy was to design how my solution should work and then produce the HTML and PHP to realize it. When I got stuck, I searched through references, forums and examples. The final release may not be the most beautiful solution, but it works.
During this section I have gotten more familiar with my server setup and my PHP interpreter as well as the actual code. I have glimpsed some techniques to trigger certain behaviours in php and gotten better at debugging php, write html and CSS. I am satisfied with the final result but I will continue to tweak during the rest of the course until submission date
Grade fulfilment
-
Grade 3: Requirements fulfilled.
-
Grade 4: Requirements fulfilled.
-
Grade 5: Requirements fulfilled. Read.php was gave me some headache until I figured out a nice solution
S06
Target grade: 5
Native languages: These languages will always retain their niche due to performance and platform
interaction capabilities Ex. Delphi, C/C++, Go etc.
Compiled languages: Compiled languages generally compile to C and then down to assembler/machine. These
languages often retain some hardware interactions, but the implementation is out of the developer’s control. These
languages are nice to use if the middle and low-level implementations is beyond the scope of your project but you
still want the platform compatibility. Ex. Common Lisp, GHC Haskell, Perl
Interpreted/Scripted: These languages are light and easier to approach than the native ones. They are
generally platform independent which is a sell point in any business. They are generally abstracted from hardware
and must utilize native language middleware to interact with hardware efficiently Ex. Java, Python, JavaScript
My future language will most probably be C/C++. I really like the control I get from using these languages. The need to be thorough and extremely vigilant all the time is challenging and keeps me on my toes. Maybe I'll also dive into assembler and shader script language along the way
If I were to do web development I would most probably stay in the backend and use JavaScript and PHP but hopefully I'll there will be a core somewhere that utilizes C/C++. That would be my work of choice
My recommendations on languages and framework for an employer would be JavaScript/TypeScript/React/Redux.
Selling points: JavaScript can be used front and backend. Typescript is JavaScript without errors. and finally
React/Redux for performance and nice structure.
All these languages and framework can be used on any platform.
In this section of the course I have reflected on the different approaches to solving specific tasks. Also the pros and cons of existing frameworks and how I view them
Grade fulfilment
-
Grade 3: Requirements fulfilled.
-
Grade 4: Requirements fulfilled.
-
Grade 5: Requirements fulfilled.
S07
Target grade: 5
.Net is a template system founded on C# and Asp.Net. This makes it easy to quickly produce large, efficient and complex websites or applications. These features are probably why this system is gaining popularity in the market. With a simple command a skeleton for a website or an application is produced. Multiple options to customize builds are available making the initial phase of a project fast and easy
However, this system is also complex, consists of multiple (non-compatible) versions that makes it hard to find good reference material. In my own opinion the references for Java and C/C++ is much better
Personal reflection
I must say that .Net is one of the worst experiences I have had in coding yet. I would rather code assembler than using C# and ASP.Net etc. I feel confused all the time, the guides and references available doesn't match and I have had a hard time locating good solid, working advice online. There doesn't seem to be a general approach how to use .Net in the community. It is said that C# came to be as a way to make it easier to code compared to C/C++. Well the result seems worse actually. I am not an experienced C/C++ coder but debugging C/C++ is childsplay compared to the tsunamis of BS that is produced using this "easier" language. The pros are of course the memory management. But in my opinion, a coder that considers memory will be a thorough coder.
Grade fulfilment
-
Grade 3: Requirements fulfilled.
-
Grade 4: Requirements fulfilled.
-
Grade 5: Requirements fulfilled.
S08
Target grade: 5
During this section we have analysed some webpages according to performance. I have used some of the analysis tools before but now my analysis was more thorough. The first thing I noticed was that some pages would download pretty fast but was slow to render. Others would take more time to download but were interactive as soon as download was complete.
One of the sites analysed was one of my servers. The report suggested that I should use different image formats and remove unused CSS references. The performance gain would not be that great but a little bit. What I noticed was that response time and download speed was good. This is nice to hear because the server in question is running on a system with limited resources. I have been fearing that this would have a large impact. This data says otherwise.
During this section I have been taking mental notes of how to avoid bottlenecking in my code. To enable vital code to load first and then incrementally add on functionality as the data becomes available. This produces a fast site that will have functionality with only partially loaded page.
Members: Isak Zayane, Oscar Odelstav, Simon Westerdahl and Fredrik Lémon Larsson. The data collected: https://drive.google.com/file/d/1_wnIwN9Sp8wWEU1myFZWR4r_xUvVyk82/view The pages compared are GitLab, which is hosted on Fredrik's server, Androids Developer page, and Wikipedia. Overall Wikipedia has the best time on each time measure. If you compare AndroidDev and Wikipedia, which both is for documentation but AndroidDev finished 100 times slower than Wikipedia. One could argue that AndroidDev should apply a wiki instead of their layout, to get better overall speed time. The AndroidDev is also about 10 times slower on first CPU idle time, so their page will not be as quickly responsive as Wikipedia either. We chose Fredrik’s GitLab page just to see its response time for curiosity. Since it’s hosted on a server in Fredrik’s garage its surprising that it finishes 10 times faster than AndroidDev. Since AndroidDev got established business servers in comparison to Fredrik’s server. However, measuring GitLab we only measured the first login page and not further into the site. When logged in you might see slower speed since there is more security as you log in. The GitLab and Android Devs First Input Delay (FID) are 1.78 and 0.59 seconds respectively. Going above 2-3 seconds can be too long for a user to have a pleasant experience, whilst Wikipedia's FID is 0.05, which is splendid! An important metric in the performance section is Time to Interactive. Wikipedia, having the best time at 0.7 seconds while GitLab and AndroidDe have 8.4 and 14.5 seconds respectively. Having 14.5 seconds on TTI is not good at all and users might end up using other sources than AndroidDev while for example looking up guides for Android Studio.
Grade fulfilment
-
Grade 3: Requirements fulfilled.
-
Grade 4: Requirements fulfilled.
-
Grade 5: Requirements fulfilled.
S09
Target grade: 5
Implement https. Today this is almost a necessity but it's worth to be reminded. Using secure transfer makes your data private during transfer. It is still good practice to not push user-credentials in "clear-text" even on a secure connection.
Libraries is something most developers use frequently. Most of the time they are linked via Maven. But it is not common to review used libraries for security flaws and back-doors. I recently read an article about security issues within common libraries. Some flaws were just bugs. But some were deliberately inserted. To review included libraries is not something commonly performed in industry and this is a huge problem. The next best thing if not reviewing a library is to use well-known libraries/frameworks. Due to many users errors within these libraries/frameworks should be spotted earlier and removed. But there is never a guaranty
Speaking of libraries and frameworks. Until you know how to implement proper security by yourself it is best practice to use libraries and framework for this task. You will probably end up with better security than implementing by hand. Remember, an attacker need only one hole. You need to find all the holes...
Last but not least, never ever use a development environment for production. A dev environment is configured to make it easy to implement your site/software. But this also makes it easy for the hacker. Some popular servers have had to implement some default security in their development environment due to the fact that many put the server online in development configuration with disastrous consequences
I have been hosting 3 servers for some years and most of the server-side problems discussed was not new to me. But the part about sessions and tokens is interesting. I haven't implemented this kind of security on any website/app yet. We will probably do it in our project.
Grade fulfilment
-
Grade 3: Requirements fulfilled.
-
Grade 4: Requirements fulfilled.
-
Grade 5: Requirements fulfilled.
S10
Target grade: 5
At the beginning of the project me and Simon decided to split our responsibilities. Simon was to concentrate on the front-end part and I were to take care of hosting, security and back-end. After some discussion we landed on React.JS to be used in frontend and PHP for the backend. We decided React.JS because we've been using it before and want to become better at it. We chose PHP because I wanted to learn it.
Development started with the setup of two projects (frontend/backend) on my server. I then did a basic implementation in React.JS to have when setting up the backend. After this was done I setup the host with a separate MySQL-server and xammp-stack. I decided not to use the DBMS included in xammp because it is a little bit tricky to design some behaviours that I want. Then SSL was implemented on the server. I made a request to a CA and got a certificate that was plugged into the stack and tested. With the SSL in place I decided not to require Simon to implement further security. SSL was enough for this project. A DDNS was also setup to enable both developers to talk to the same server and database.
Initially a PHP-api was produced with 2 endpoints. When all was working more endpoints with more functions was added. After this initial sprint I decided to redesign the API to a single endpoint. This prevented the cluttering I was beginning to sense in the back-end. Using this single endpoint, a handler-script was introduced into the front-end project. This script would be the endpoint Simon would use throughout this project, protecting his work from my redesigns and debugging-measures.
When most of the methods were implemented and tested I decided to redesign the back-end data-flow. This was because I wanted to have a better view of how data was flowing, what went right and if so, what went wrong. Due to the handler-script on the front-end side this was implemented without affecting Simon's work. The result will consume more bandwidth but the result is easier debugging.
Finally I produced our groups presentation video. It was hard to keep it light and simple without losing the important details that we wanted to mention. I do, however, think the result was good and represents our effort. And I apologize for the long intro.
Simon and I have worked together before and we work very well together. During this project it has been a little bit hard to find time and focus because we also are doing our thesis. Of course, it is up to us to prioritize but I'll mention it anyway. I found it hard to prioritize between the two. Especially during these times with Corona.
During this project my understanding and skill in PHP has greatly improved. Because some of my work have ben done in React.JS I have learned more about states and promises
This course has been a little bit different from what I've seen before. Many things are good, some may improve.
- Working from a forked repo with example code was excellent!
- Really good tasks. Really liked the specification for each grade!
- I know that many really enjoyed your lectures. I however did not. Not because they were bad but because of how I learn. You always seem to provide options for solutions but seldom state "this is the way to do it. This is, however, not a deficiency on your part but on mine. If I were to ask something from you is to include or emphasis "best practice" on different problems during lectures.
- Maybe provide a structure to work within? I have felt insecure at times how you want the structure to be.
Having stated above I want to convey my gratitude for this course. It is really nice to have a lecturer that know the subject by heart. It brings confidence into the classroom and it rubs off on the students. I would have enjoyed discussing the finer point in web-development security, web-assembler and multi-platform implementations with you if there were time for it.
Grade fulfilment
-
Grade 3: Requirements fulfilled.
-
Grade 4: Requirements fulfilled.
-
Grade 5: Requirements fulfilled.


The following table shows a live view of the battery cell voltages along with their recorded minimum, maximum, maximum deviation and current warning/alert state.
Try resizing the window or using a mobile phone to see how the table adapts to the screen width. The table will also keep the selected sorting over data updates.
Hint: if you don't have live battery cell data, click the generator button to create some random values. The random data is only generated in your browser, not on the module.
See DataTables manual for all options and API methods available.


Find the official website for: {{ task.input.company }}
Do not give Yelp pages, LinkedIn pages, etc.
Include the http:// prefix from the website