-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
412 lines (261 loc) · 25 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Juan R. Lara</title>
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<meta property="og:type" content="website">
<meta property="og:title" content="Juan R. Lara">
<meta property="og:url" content="http://juanrlara.com/index.html">
<meta property="og:site_name" content="Juan R. Lara">
<meta name="twitter:card" content="summary">
<meta name="twitter:title" content="Juan R. Lara">
<meta name="twitter:creator" content="@JRLtechwriting">
<link rel="alternate" href="/atom.xml" title="Juan R. Lara" type="application/atom+xml">
<link href="//fonts.googleapis.com/css?family=Source+Code+Pro" rel="stylesheet" type="text/css">
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css" integrity="sha384-1q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs7" crossorigin="anonymous">
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css" integrity="sha384-XdYbMnZ/QjLh6iI4ogqCTaIjrFk87ip+ekIjefZch0Y+PvJ8CDYtEs1ipDmPorQ+" crossorigin="anonymous">
<link rel="stylesheet" href="/css/styles.css">
<!-- Google Analytics -->
<script type="text/javascript">
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-93187547-1', 'auto');
ga('send', 'pageview');
</script>
<!-- End Google Analytics -->
</head>
<body>
<nav class="navbar navbar-inverse">
<div class="container">
<!-- Brand and toggle get grouped for better mobile display -->
<div class="navbar-header">
<button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#main-menu-navbar" aria-expanded="false">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
</div>
<!-- Collect the nav links, forms, and other content for toggling -->
<div class="collapse navbar-collapse" id="main-menu-navbar">
<ul class="nav navbar-nav">
<li><a class="active"
href="/index.html">Home</a></li>
<li><a class=""
href="/archives/">Archives</a></li>
</ul>
<!--
<ul class="nav navbar-nav navbar-right">
<li><a href="/atom.xml" title="RSS Feed"><i class="fa fa-rss"></i></a></li>
</ul>
-->
</div><!-- /.navbar-collapse -->
</div><!-- /.container-fluid -->
</nav>
<div class="container">
<div class="blog-header">
<h1 class="blog-title">Juan R. Lara</h1>
</div>
<div class="row">
<div class="col-sm-8 blog-main">
<article id="post-SOAP-and-REST-Overview" class="article article-type-post" itemscope itemprop="blogPost">
<header class="article-header">
<h1 itemprop="name">
<a class="article-title" href="/2017/03/15/SOAP-and-REST-Overview/">SOAP and REST Overview</a>
</h1>
</header>
<div class="article-meta">
<div class="article-datetime">
<a href="/2017/03/15/SOAP-and-REST-Overview/" class="article-date"><time datetime="2017-03-16T02:46:53.000Z" itemprop="datePublished">2017-03-15</time></a>
</div>
</div>
<div class="article-inner">
<div class="article-entry" itemprop="articleBody">
<h1 id="SOAP-and-REST"><a href="#SOAP-and-REST" class="headerlink" title="SOAP and REST"></a>SOAP and REST</h1><p>This article gives an overview of SOAP and REST. SOAP and REST are two approaches to creating web services. Both approaches create web services for machine-to-machine interactions over a network. Most web services are implemented as either SOAP APIs or REST APIs communicating over the HTTP protocol. It’s important to note that SOAP is a protocol specification while REST is an architectural style.</p>
<h2 id="SOAP-Specification"><a href="#SOAP-Specification" class="headerlink" title="SOAP Specification"></a>SOAP Specification</h2><p><em>Simple Object Access Protocol</em></p>
<p>The <a href="http://www.w3.org/TR/soap12/" target="_blank" rel="external">SOAP specification</a> defines a protocol for using XML to exchange information. SOAP messages travel between SOAP nodes, from sender to receiver. The SOAP specification lets developers create very well-defined web services with predictable behavior. SOAP web services are also supported by many powerful developer and client tools.</p>
<h3 id="SOAP-Messages"><a href="#SOAP-Messages" class="headerlink" title="SOAP Messages"></a>SOAP Messages</h3><p>Each SOAP messages is an XML documents with the following elements:</p>
<ul>
<li>Envelope—identifies the message as a SOAP message. Contains the Header (optional), Body, and Fault (optional) elements.</li>
<li>Header—optional element used to add information not directly part of the message body, but useful to processing the message and extending capability.</li>
<li>Body—mandatory element carrying the message’s main information.</li>
<li>Fault—optional element used to communicate errors in message processing.</li>
</ul>
<p>Simple SOAP message:</p>
<pre><code><?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
</soap:Header>
<soap:Body>
<m:GetPrice>
<m:Item>Balloon</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>
</code></pre><p>Once a receiver processes a SOAP message, the receiver sends back its own SOAP message as a response. For a detailed example of SOAP messages and message processing, see the <a href="https://www.w3.org/TR/soap12-part0/ W3C SOAP Primer" target="_blank" rel="external">W3C SOAP Primer</a></p>
<p>In addition to defining SOAP message structure, the SOAP specification (<a href="https://www.w3.org/TR/soap12-part1/" target="_blank" rel="external">https://www.w3.org/TR/soap12-part1/</a>) also describes the following:</p>
<ul>
<li>Processing Model—defines how nodes process messages</li>
<li>Extensibility Model—describes how to add capabilities to the SOAP messaging framework</li>
<li>Protocol Binding Framework—defines how the messaging framework functions in a specific protocol like HTTP or SMTP </li>
</ul>
<h3 id="WSDL"><a href="#WSDL" class="headerlink" title="WSDL"></a>WSDL</h3><p><em>Web Service Description Language</em></p>
<p>WSDL is an XML format often used to describe SOAP web services. WSDL is not part of the SOAP specification and has its own <a href="https://www.aw3.org/TR/wsdl" target="_blank" rel="external">specification</a>. WSDL can completely describe a web service as a series of service definitions of the data the each service accepts, the operations each service performs on the data, and the location of each service. Once a web service is described in a WSDL file, code generation tools can use the WSDL to generate documentation and clients to access the web service. </p>
<h2 id="REST-Architecture-Style"><a href="#REST-Architecture-Style" class="headerlink" title="REST Architecture Style"></a>REST Architecture Style</h2><p><em>Representational State Transfer</em></p>
<p>Developers use the REST architectural style to create fast, scalable, simple, and modifiable web services well-suited to working over HTTP.</p>
<p>The REST architectural style defines six constraints for architectures based on networks like the Internet:</p>
<ul>
<li>Client-server—clear separation between client and server. Enables modifiable clients and servers which can evolve independently of the each other.</li>
<li>Stateless—the server does not store any information related to the state of the client. The client’s request contains all the information needed to understand and process the request. As a result, servers recover from a failed requests quicker and use less storage.</li>
<li>Cacheable—data from the server to the client must be labeled as cacheable or non-cacheable. If the data is cacheable, the client may reuse the data for equivalent requests. This constraint reduces the number of requests and improves network traffic.</li>
<li>Uniform Interface—all clients, servers, and components within the network must communicate using a common interface. Information flows through the network in a standardized form and allows all components to evolve independently. See below for <a href="#Uniform-Interface">additional constraints on the uniform interface</a>.</li>
<li>Layered System—additional layers can be added to the network with the constraint that components within one layer cannot require knowledge of other layers. Layers such as load balancing layers can be added to improve network performance without disrupting clients and servers. </li>
<li>Code on demand (optional)—in cases where it’s beneficial, servers can push code and additional features to the client.</li>
</ul>
<h3 id="Uniform-Interface"><a href="#Uniform-Interface" class="headerlink" title="Uniform Interface"></a>Uniform Interface</h3><p>The uniform interface constraint is the central feature of REST architectures.</p>
<p>REST defines the following constraints on the interface:</p>
<ul>
<li>Resource Identification—all information in a REST architecture is accessed as a resource mapped to a resource identifier. The resource at a resource identifier can be empty or a set of resource representations and/or resource identifiers. Servers and clients may update the resource value. The resource author must create a resource identifier which adequately describes the resource value.</li>
<li>Manipulation of Resources Through Representations—when REST components interact with each other, they pass complete representations of the resources of data. Representations consist of data and metadata, all the information you need to define the resource and it’s state and act on it. Metadata can include the client’s preferred data type for the representation.</li>
<li>Self-descriptive Messages—to satisfy the stateless server constraint, messages must contain all the information needed to process the message.</li>
<li>Hypermedia as the Engine of Application State—to satisfy the client-server constraint, clients discover additional resources by using hypermedia from the resource indicators contained within the resource representation of a response from the server.</li>
</ul>
<h3 id="REST-Web-Services"><a href="#REST-Web-Services" class="headerlink" title="REST Web Services"></a>REST Web Services</h3><p>Using the REST architecture style, you can implement a REST Web Service as a REST API using HTTP as the common interface. Because REST was created with the Internet in mind, many of the architecture constraints can be satisfied with common web technologies like HTTP. REST does not specify a required representation format and can support multiple format types. For example, REST web services commonly support JSON and XML message formats.</p>
<p>Simple REST Example:</p>
<pre><code>GET http://example.com/student/{id}
</code></pre><p>Response in JSON:</p>
<pre><code>{
"birthDate":"1978-09-16T12:03:26.590Z",
"firstName":"Jane",
"id":"567",
"lastName":"Doe"
}
</code></pre><p>For a detailed description of the REST architectural style, see <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm" target="_blank" rel="external">http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm</a>.</p>
<h2 id="REST-Popularity"><a href="#REST-Popularity" class="headerlink" title="REST Popularity"></a>REST Popularity</h2><p>Over time, REST web services became more popular than SOAP web services and new web services commonly use the REST architecture style. SOAP, while supported by powerful tools and WSDL, adds considerable overhead to each message and to the implementation code. Developers tend to choose REST for it’s HTTP design and flexible, simple message format.</p>
</div>
<footer class="article-footer">
<a data-url="http://juanrlara.com/2017/03/15/SOAP-and-REST-Overview/" data-id="cj0bsoedb000114qo31s9b6lu" class="article-share-link">
<i class="fa fa-share"></i> Share
</a>
</footer>
</div>
</article>
<article id="post-Write-the-Docs-SF-Video-Documentation" class="article article-type-post" itemscope itemprop="blogPost">
<header class="article-header">
<h1 itemprop="name">
<a class="article-title" href="/2016/10/05/Write-the-Docs-SF-Video-Documentation/">Write the Docs SF: Video Documentation</a>
</h1>
</header>
<div class="article-meta">
<div class="article-datetime">
<a href="/2016/10/05/Write-the-Docs-SF-Video-Documentation/" class="article-date"><time datetime="2016-10-05T17:40:04.000Z" itemprop="datePublished">2016-10-05</time></a>
</div>
</div>
<div class="article-inner">
<div class="article-entry" itemprop="articleBody">
<p>On Thursday, September 29th, <a href="https://www.meetup.com/Write-the-Docs-SF/events/233979652/" title="Write the Docs SF" target="_blank" rel="external">Write the Docs SF</a> put together a Meetup Atlassian Dev Den. The topic was video documentation and the speaker approached the field from a refreshing angle. </p>
<h2 id="Tech-Comm-Meets-Youtube-Sirajology"><a href="#Tech-Comm-Meets-Youtube-Sirajology" class="headerlink" title="Tech Comm Meets Youtube: Sirajology"></a>Tech Comm Meets Youtube: Sirajology</h2><p>Presenting at this event was Siraj Raval who runs the YouTube channel <a href="https://www.youtube.com/channel/UCWN3xxRkmTPmbKwht9FuE5A" title="Sirajology" target="_blank" rel="external">Sirajology</a>. His channel focuses on machine learning and Siraj’s mission is to inspire developers. Siraj produces a five-minute video a week. In each video, he focuses on a working application which illustrates a programming concept. After introducing the concepts behind the application, he steps through and explains the application’s code. Siraj shared with us some of the things he’s learned work and don’t work in his videos.</p>
<h3 id="What-Works-in-Video-Documentation"><a href="#What-Works-in-Video-Documentation" class="headerlink" title="What Works in Video Documentation"></a>What Works in Video Documentation</h3><ul>
<li>Usable Applications—the most popular videos give you a working piece of code that you can try out yourself. Each video goes over the code and Siraj uses a red arrow indicator to step through the code.</li>
<li>Five Minute Maximum—each video should be around five minutes long. Siraj cuts eight to ten minutes of footage down to five.<br>Consistent Content—to increase subscribers, you need a consistent release schedule.</li>
<li>Text in Video Thumbnail—people are more likely to click on a video when the title is in the video thumbnail:</li>
</ul>
<p><img src="/2016/10/05/Write-the-Docs-SF-Video-Documentation/sirajologyThumbnailExample.jpg" alt="" title="Thumbnail with text example"></p>
<h3 id="What-Doesn’t-Work-in-Video-Documentation"><a href="#What-Doesn’t-Work-in-Video-Documentation" class="headerlink" title="What Doesn’t Work in Video Documentation"></a>What Doesn’t Work in Video Documentation</h3><ul>
<li>Too Much Code—the applications in the video should have less than 100 lines of code.</li>
<li>Uncommon Programming Languages—code should be written in a popular programming language.</li>
<li>Less Technical Videos—Siraj tried videos focused on comedy and technology. They didn’t get as many views.</li>
</ul>
<h2 id="Is-This-Applicable-to-Enterprise-Documentation"><a href="#Is-This-Applicable-to-Enterprise-Documentation" class="headerlink" title="Is This Applicable to Enterprise Documentation?"></a>Is This Applicable to Enterprise Documentation?</h2><p>If you watch one of Siraj’s videos, you’ll notice the tone and content are very different from what you’ll see in an enterprise software documentation video. His videos use humor, pop culture reference, and memes to engage the viewer. Would this kind of content be effective in an enterprise software community? I believe this question is answered by the fact that enterprise software companies approach Siraj to create videos for their developers.</p>
<h2 id="What-Type-of-Content-is-Best-Served-by-Video"><a href="#What-Type-of-Content-is-Best-Served-by-Video" class="headerlink" title="What Type of Content is Best Served by Video?"></a>What Type of Content is Best Served by Video?</h2><p>At the meetup, we discussed what content should have a video and what shouldn’t. Attendees from Atlassian and Salesforce also added their input. These guidelines came out of the discussion:</p>
<p>Video best serves these four topic types:</p>
<ul>
<li>Topics that answer “Why?”, “When?”, or “Why this vs that?” Topics which are mostly click-through do not make the best videos.</li>
<li>Troubleshooting is useful to see in a video.</li>
<li>Topics which describe visuals should be videos. For example, explanations of drag-and-drop elements.</li>
<li>Overviews make good videos: What are all the pieces you’ll need to touch to accomplish a task? Videos should give you just enough information to know what you need to do.</li>
</ul>
<p>Videos should whet the appetite of the viewer and inspire the viewer to search for the long form documentation. For example, videos that show how to create and run a small script inspire the user to read the documentation to learn how to expand upon their script.</p>
<h2 id="The-Future-of-Professional-Explainers"><a href="#The-Future-of-Professional-Explainers" class="headerlink" title="The Future of Professional Explainers"></a>The Future of Professional Explainers</h2><p>My co-worker introduced me to the term “professional explainer” for someone that works in tech comm. It was interesting to see a professional explainer like Siraj find his niche and audience. Siraj predicts that the demand for professional explainers will significantly increase in the next five years. Much of the documentation that exists now is boring and many of the people with the technical know-how to explain a concept are not always good presenters. As the number of developers in the world increases, there will be a need for people that can not only explain concepts accurately but explain them in an engaging manner.</p>
</div>
<footer class="article-footer">
<a data-url="http://juanrlara.com/2016/10/05/Write-the-Docs-SF-Video-Documentation/" data-id="cizzzp8wg0001loqozf48o6av" class="article-share-link">
<i class="fa fa-share"></i> Share
</a>
</footer>
</div>
</article>
<article id="post-Write-the-Docs-Lightning-Talks" class="article article-type-post" itemscope itemprop="blogPost">
<header class="article-header">
<h1 itemprop="name">
<a class="article-title" href="/2016/03/30/Write-the-Docs-Lightning-Talks/">Write the Docs: Lightning Talks</a>
</h1>
</header>
<div class="article-meta">
<div class="article-datetime">
<a href="/2016/03/30/Write-the-Docs-Lightning-Talks/" class="article-date"><time datetime="2016-03-30T18:09:11.000Z" itemprop="datePublished">2016-03-30</time></a>
</div>
</div>
<div class="article-inner">
<div class="article-entry" itemprop="articleBody">
<p>This month Google hosted the Write The Docs Meetup at their downtown SF office. Eleven people (including me!) gave five-minute presentations about a wide variety of documentation topics. The presentations were recorded and are available <a href="http://bit.ly/wtdsflightningtalks" target="_blank" rel="external">here</a>. Here are a few of my favorites:</p>
<h2 id="The-easiest-way-to-create-professional-looking-illustrations-and-diagrams"><a href="#The-easiest-way-to-create-professional-looking-illustrations-and-diagrams" class="headerlink" title="The easiest way to create professional-looking illustrations and diagrams"></a>The easiest way to create professional-looking illustrations and diagrams</h2><p>Tom Johnson</p>
<p>Tom’s presentation went over some guidelines for creating useful diagrams. Diagrams should be minimalist and serve to reduce cognitive load. Especially interesting was Tom’s introduction of the Noun Project, an online library of icons.</p>
<h2 id="Using-Twine-as-interactive-documentation"><a href="#Using-Twine-as-interactive-documentation" class="headerlink" title="Using Twine as interactive documentation"></a>Using Twine as interactive documentation</h2><p>Al Nelson</p>
<p>Twine is an open-source tool for creating interactive, nonlinear stories like choose-your-own-adventure books. Al experimented with this tool to create an interactive help system. See the demo at <a href="http://philome.la/musegarden/interactive-documentation-with-twine/play" target="_blank" rel="external">http://philome.la/musegarden/interactive-documentation-with-twine/play</a>.</p>
<h2 id="MediaWiki-as-a-Documentation-Platform-The-Genesys-Documentation-Story"><a href="#MediaWiki-as-a-Documentation-Platform-The-Genesys-Documentation-Story" class="headerlink" title="MediaWiki as a Documentation Platform-The Genesys Documentation Story"></a>MediaWiki as a Documentation Platform-The Genesys Documentation Story</h2><p>Juan Lara</p>
<p>As far as I know, only two companies use PonyDocs, us and Splunk. I used this opportunity to let more people know about PonyDocs and how Genesys came to use PonyDocs/MediaWiki to host our documentation. It would be great to see the PonyDocs platform adopted by more people.</p>
<h2 id="Plug-for-Tanya’s-STC-Talk"><a href="#Plug-for-Tanya’s-STC-Talk" class="headerlink" title="Plug for Tanya’s STC Talk"></a>Plug for Tanya’s STC Talk</h2><p>During my speech, I mentioned the extensibility MediaWiki and promoted my coworker’s STC presentation on JIRA to PonyDocs release note automation. This really got the room’s attention and people asked me about it after the meeting. This is one of the messages I received:</p>
<p>Could you tell me a bit more about the JIRA –> PonyDocs workflow? I currently have to read through our JIRA by hand and curate the issues myself for release notes. Would love to know how you handle this.</p>
<p>There is definitely an interest for this kind of automation and I think my co-worker’s presentation will be very well received.</p>
</div>
<footer class="article-footer">
<a data-url="http://juanrlara.com/2016/03/30/Write-the-Docs-Lightning-Talks/" data-id="cizzzp8wa0000loqo6i8epdw9" class="article-share-link">
<i class="fa fa-share"></i> Share
</a>
</footer>
</div>
</article>
</div>
<div class="col-sm-3 col-sm-offset-1 blog-sidebar">
<div class="sidebar-module sidebar-module-inset">
<h4>About</h4>
<p>This blog focuses on technical communication and its supporting technologies.</p> <p>Follow me: <a href="https://twitter.com/JRLtechwriting">@JRLtechwriting</a>, <a href="https://www.linkedin.com/in/juan-lara">LinkedIn</a></p>
</div>
<div class="sidebar-module">
<h4>Archives</h4>
<ul class="sidebar-module-list"><li class="sidebar-module-list-item"><a class="sidebar-module-list-link" href="/archives/2017/03/">March 2017</a><span class="sidebar-module-list-count">1</span></li><li class="sidebar-module-list-item"><a class="sidebar-module-list-link" href="/archives/2016/10/">October 2016</a><span class="sidebar-module-list-count">1</span></li><li class="sidebar-module-list-item"><a class="sidebar-module-list-link" href="/archives/2016/03/">March 2016</a><span class="sidebar-module-list-count">1</span></li></ul>
</div>
<div class="sidebar-module">
<h4>Recents</h4>
<ul class="sidebar-module-list">
<li>
<a href="/2017/03/15/SOAP-and-REST-Overview/">SOAP and REST Overview</a>
</li>
<li>
<a href="/2016/10/05/Write-the-Docs-SF-Video-Documentation/">Write the Docs SF: Video Documentation</a>
</li>
<li>
<a href="/2016/03/30/Write-the-Docs-Lightning-Talks/">Write the Docs: Lightning Talks</a>
</li>
</ul>
</div>
</div>
</div>
</div>
<footer class="blog-footer">
<div class="container">
<div id="footer-info" class="inner">
© 2017 Juan Ramon Lara<br>
Powered by <a href="http://hexo.io/" target="_blank">Hexo</a>
</div>
</div>
</footer>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js" integrity="sha384-8gBf6Y4YYq7Jx97PIqmTwLPin4hxIzQw5aDmUg/DDhul9fFpbbLcLh3nTIIDJKhx" crossorigin="anonymous"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js" integrity="sha384-0mSbJDEHialfmuBBQP6A4Qrprq5OVfW37PRR3j5ELqxss1yVqOtnepnHVP9aJ7xS" crossorigin="anonymous"></script>
<script src="/js/script.js"></script>
</body>
</html>