At least 24 people killed by landslides, floods in Kenya
by Agency ReportLandslides and floods caused by torrential rains have killed at least 24 people in Kenya, officials said on Saturday.
At least 17 people were buried overnight by landslides in West Pokot County, north of the capital Nairobi, county commissioner Apollo Okello told dpa.
A family of seven people was swept away by floods in another part of the county, Okello said.
An undisclosed number of people were missing on Saturday, while infrastructure including roads and bridges had been damaged, according to Emmanuel Ameme, a coordinator for the National Government Affirmative Action Fund.
READ ALSO: Why some presidential aides were sacked — Buhari
Heavy rainfall continued on Saturday, with the Kenya Red Cross sending rescue teams into affected areas.
“The rivers are swelling again, so the damage might even be worse,” Okello told dpa.
dpa/NAN


{% extends "usep_templates/base.html" %} {% block head_title %}Collections of Greek and Latin Inscriptions in the USA{% endblock head_title %} {% block page_title %}Collections of Greek and Latin Inscriptions in the USA{% endblock page_title %} {% block list_of_states %}
View US Epigraphy Collections in a full screen map
{{ item.collection_code }}
[More...]
{{ item.collection_name }}
{{ item.collection_address }}
{{ item.collection_description|safe }}


Ensuring that all your plants are consistently watered is actually pretty difficult. Oxygen is an app that helps to solve those problems.
With an easy to use interface for creating a plant watering schedule tailored to each individual plant, Oxygen will remind users when it's time to feed that foliage and quench your plants' thirst.
A small fee of $3 a month to keep those plant babies happy!
Pay at a discounted price for an annual payment of $30!
Project Leader!
Marketing: Landing page and "About" section of webpage!
React1: Forms layout and styling!
React 2 Developer: Forms on the Register and Sign Up sections!
React 2 Developer: Forms on the Register and Sign Up sections!
Lead iOS Engineer: Lead the creation of the Oxygen app!
iOS Engineer: Team member in the creation of the app!
iOS Engineer: Team member in the creation of the app!
Back-End
Back-End


|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
| Interface Summary | |
|---|---|
| Function.IBinary<A,B,C> | |
| Function.IUnary<A,B> | |
| IIterableIterator<T> | Makes iterators easily usable in for each loops. |
| INamedMatchResult | |
| Predicate.IBinary<A,B> |
| Class Summary | |
|---|---|
| BriefLogFormatter | |
| Function | |
| IterableAdapter<T> | |
| NamedMatcher | |
| NamedPattern | |
| NamedSubstitution | |
| Pair<L,R> | |
| Predicate | |
| Predicate.BinaryFalse<A,B> | |
| Predicate.BinaryTrue<A,B> | |
| Predicate.ComposedFirst<A,B,C> | |
| Predicate.Equals<T> | |
| UniqueQueue<E> | A Queue in which every element is only inserted once. |
| Exception Summary | |
|---|---|
| InternalSynopticException |
Provides utility classes.
|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |


--- title: "All Posts by Category" excerpt: "Lists all pages by category" permalink: /categories/ layout: archive header: overlay_image: /assets/images/delfi-de-la-rua-152121-h.jpg caption: "Photo: [**Delfi de la Rua / Unsplash**](https://unsplash.com)" --- {% include group-by-array collection=site.pages field="categories" %} {% for tag in group_names %} {% assign posts = group_items[forloop.index0] %}


Each exercise is in a file in the exercises
folder named something like e0n-topic.html
, and it has a corresponding Sass partial in the styles
folder, _e0n-topic.scss
. Your mission, should you choose to accept it, is to play with the styling in each exercise to accomplish the stated goal. Preview each page by following the links below.


How to create additional properties
- Create property class that implements
IProperty
ref interface. Implement interface members.
- If property can be automatically imported from repository, make the class implement
IImportable
ref interface. Implement interface members.
- If property can be checked at repository, make the class implement
ICheckable
ref interface. Implement interface members.
- All done! Property is created. There is no need to add property to Inversion of Control, it is done automatically using reflection.
- HINTS:
- Methods from
PropertyExtensions
ref class can be used to help implement some properties.
- There is description for each interface member in API documentation, which can help with implementation.
- Already implemented properties can be checked to help implement the new ones.


Visualization
Word Clouds
Sentiment Analysis
Sentiment Analysis
Click on dropdown menu to see the sentiment analysis of each star rating.
Data:
One Star
Two Star
Three Star
Four Star
Five Star


| 1 | /** | |
| 2 | * Licensed to the Apache Software Foundation (ASF) under one or more | |
| 3 | * contributor license agreements. See the NOTICE file distributed with | |
| 4 | * this work for additional information regarding copyright ownership. | |
| 5 | * The ASF licenses this file to You under the Apache License, Version 2.0 | |
| 6 | * (the "License"); you may not use this file except in compliance with | |
| 7 | * the License. You may obtain a copy of the License at | |
| 8 | * | |
| 9 | * http://www.apache.org/licenses/LICENSE-2.0 | |
| 10 | * | |
| 11 | * Unless required by applicable law or agreed to in writing, software | |
| 12 | * distributed under the License is distributed on an "AS IS" BASIS, | |
| 13 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |
| 14 | * See the License for the specific language governing permissions and | |
| 15 | * limitations under the License. | |
| 16 | */ | |
| 17 | ||
| 18 | package org.apache.commons.cli; | |
| 19 | ||
| 20 | /** | |
| 21 | * Thrown when an option requiring an argument | |
| 22 | * is not provided with an argument. | |
| 23 | * | |
| 24 | * @version $Id$ | |
| 25 | */ | |
| 26 | public class MissingArgumentException extends ParseException | |
| 27 | { | |
| 28 | /** | |
| 29 | * This exception {@code serialVersionUID}. | |
| 30 | */ | |
| 31 | private static final long serialVersionUID = -7098538588704965017L; | |
| 32 | ||
| 33 | /** The option requiring additional arguments */ | |
| 34 | private Option option; | |
| 35 | ||
| 36 | /** | |
| 37 | * Construct a new MissingArgumentException | |
| 38 | * with the specified detail message. | |
| 39 | * | |
| 40 | * @param message the detail message | |
| 41 | */ | |
| 42 | public MissingArgumentException(final String message) | |
| 43 | { | |
| 44 | super(message); | |
| 45 | } | |
| 46 | ||
| 47 | /** | |
| 48 | * Construct a new MissingArgumentException | |
| 49 | * with the specified detail message. | |
| 50 | * | |
| 51 | * @param option the option requiring an argument | |
| 52 | * @since 1.2 | |
| 53 | */ | |
| 54 | public MissingArgumentException(final Option option) | |
| 55 | { | |
| 56 | this("Missing argument for option: " + option.getKey()); | |
| 57 | this.option = option; | |
| 58 | } | |
| 59 | ||
| 60 | /** | |
| 61 | * Return the option requiring an argument that wasn't provided | |
| 62 | * on the command line. | |
| 63 | * | |
| 64 | * @return the related option | |
| 65 | * @since 1.2 | |
| 66 | */ | |
| 67 | public Option getOption() | |
| 68 | { | |
| 69 |
1
1. getOption : mutated return of Object value for org/apache/commons/cli/MissingArgumentException::getOption to ( if (x != null) null else throw new RuntimeException ) → KILLED |
return option; |
| 70 | } | |
| 71 | } | |
Mutations | ||
| 69 |
1.1 |


latex with vim
It is about time to start writing my thesis. For the occasion, I decided to move over vim (I was previously a user of Texpad).
I want to briefly describe my basic configuration in a blog post with the hope it could be useful to someone else in the future.
At first, I decided to use vimtex. To install such a plugin, I relied on vim-plug, a plugin manager for vim. The repository gives clear instructions on how to complete the process.
With the command below, I downloaded the plug.vim
file in the autoload
directory of vim.
curl -fLo ~/.vim/autoload/plug.vim --create-dirs \
https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
Alternatively, as suggested by the documentation itself, it is possible to automate such a task by editing the vim configuration file (~/.vimrc
) and adding this snippet:
if empty(glob('~/.vim/autoload/plug.vim'))
silent !curl -fLo ~/.vim/autoload/plug.vim --create-dirs
\ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
autocmd VimEnter * PlugInstall --sync | source $MYVIMRC
endif
Once the plugin manager was installed, I proceeded to install vimtex
. The task is quite easy: I only needed to add the Plug 'lervag/vimtex'
entry in the vimrc
file like in the example below:
call plug#begin('~/.vim/plugged')
...
Plug 'lervag/vimtex'
...
call plug#end()
To conclude the installation, just eeload vimrc
typing :source ~/.vimrc
inside vim and then type :PlugInstall
to install the plugin.
First time I opened vim after that, I incurred in the g:tex_flavor not specified
error.
Adding let g:tex_flavor = 'latex'
to the vimrc
file fixes this warning.
As a color scheme, I am a fun of dracula which I use on every IDE.
Again, I just added a new entry (Plug 'dracula/vim', { 'as': 'dracula' }
) in the vimrc
file and ran again :PlugInstall
.
For the code completion, I first installed coc.nvim, an Intellisense engine for vim with the corresponding coc-vimtex extension for tex.
To visualize the PDF generated by LaTeX, I use Skim instead of Preview (easily installable via brew
), since it supports forward and backward search.
To automatically show the PDF after compilation in Skim, I modified my vimrc
configuration as follows:
let g:vimtex_view_method = "skim"
let g:vimtex_view_general_viewer
\ = '/Applications/Skim.app/Contents/SharedSupport/displayline'
let g:vimtex_view_general_options = '-r @line @pdf @tex'
" This adds a callback hook that updates Skim after compilation
augroup vimtex_compilation
au!
au User VimtexEventCompileSuccess call UpdateSkim()
augroup END
function! UpdateSkim()
let l:out = b:vimtex.out()
let l:tex = expand('%:p')
let l:cmd = [g:vimtex_view_general_viewer, '-r']
if !empty(system('pgrep Skim'))
call extend(l:cmd, ['-g'])
endif
if has('nvim')
call jobstart(l:cmd + [line('.'), l:out, l:tex])
elseif has('job')
call job_start(l:cmd + [line('.'), l:out, l:tex])
else
call system(join(l:cmd + [line('.'), shellescape(l:out), shellescape(l:tex)], ' '))
endif
endfunction
This is more or less my basic configuration and a decent starting point for more advanced customizations. More (much more) can be achieved by looking at the vimtex documentation.
My environment currently looks like the pic below. I have a table on content opened on the left side to quickly jump amongst files. On the right side I keep Skim opened with the autocompile active.


Leverage agile frameworks to provide a robust synopsis for high level overviews. Iterative approaches to corporate strategy foster collaborative thinking to further the overall value proposition.
Bring to the table win-win survival strategies to ensure proactive domination. At the end of the day, going forward, a new normal that has evolved from generation X is on the runway heading towards a streamlined cloud solution.
Podcasting operational change management inside of workflows to establish a framework. Taking seamless key performance indicators offline to maximise the long tail. Keeping your eye on the ball while performing a deep dive on the start-up mentality to derive convergence on cross-platform integration.
Collaboratively administrate empowered markets via plug-and-play networks. Dynamically procrastinate B2C users after installed base benefits.
Choose Your Background Color


If you configure the locale and register the locale data as explained in the
i18n guide, the time picker will honor the locale and use the day periods
("AM" and "PM") from the locale data. You can however provide a custom service, as demonstrated in this example, to
customize the days and months names the way you want to.
Timepicker in Greek


@* * Copyright 2017 Interel * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. * * New Local User Modal Template *@ @(id: String, permissions: Seq[String])


Background
- Always been in Ops or Support
- Until recently, I have never really worked closely with developers
- I have been doing Puppet since 2008 (v 0.24.7)
- First looked at testing Puppet modules about a year ago
Outline
- Why Testing
- What is Testing
- What to Test
- Next Steps
What I Thought?
- Help catch mistakes
- Test that things work
Why Didn't I Start Writing Tests Regularly?
- I was basically reimplementing my manifests in rspec
- No guidance on what to test and why to test
- Wait a sec, you mean it doesn't actually test if it works?
- Didn't understand the types of tests
So Then Why Are We Here?
- Testing configuration beyond just the manifests
- Manifests are getting more complicated
- Knowing that integration testing is coming
- Makes writing Puppet code more fun
Types of Tests
- Syntax Checking
- Linting
- Unit Tests
- Integration Tests
Syntax Checking
- Something a lot of us have done for a while
- Important, but doesn't do much
Linting
- puppet-lint and food critic
- Makes reading manifests and code easier
- Reminds you to do things like documentation
Unit Tests
- rspec-puppet
- Multiple tools in Chef
- Test the code returns the things that are expected
- In Puppet, testing the catalog
- Get syntax checking for free
Integration Tests
- Does the catalog actually apply or the run converge?
- Did it actually work?
It Is Driving Development, Right?
- Before you start writing config mgmt code
- After you found a problem in dev/prod
- As you go
Basic Stuff
- Are the packages getting marked for install?
- Is the config file getting put in the right place for this platform?
- Is the service being started?
Puppet Code
package {'httpd':
ensure => installed
}
rspec-puppet
it { should contain_package('httpd').with_ensure('installed') }
Important Config Elements
- Is the Include directive in the apache config?
- How about that Rewrite rule?
- Are the search domains in the right order?
- Are we setting the right options for SOLR?
Puppet Code
file {'/etc/ssh/sshd_config':
ensure => present,
mode => '0644',
owner => 'root',
group => 'root',
content => template('ssh/etc/ssh/sshd_config.erb')
}
rspec-puppet
it do
should contain_file('/etc/ssh/sshd_config') \
.with_mode('0644') \
.with_owner('root')
end
Let's Try That Again
it "Enable GSSAPI" do
should contain_file('/etc/ssh/sshd_config') \
.with_content(/^GSSAPIAuthentication yes/)
end
it "Enable X11 Forwarding" do
should contain_file('/etc/ssh/sshd_config') \
.with_content(/^X11Forwarding yes/)
end
Security Considerations
- Is logging enabled?
- Are we disabling display_errors in PHP?
rspec-puppet
it "Disable root login via ssh" do
should contain_file('/etc/ssh/sshd_config') \
.with_content(/^PermitRootLogin no/)
end
Environment Differences
- Is caching on in prod but off in dev?
- Is debug on in dev but off in prod?
Show me on the doll where the config touched you...


Professional translation, localization and content services
PoliLingua specializes in translation, localization and managed language solutions for clients both large and small, from corporate, government and private sectors. We’re happy to provide free price quotes for any document, user manual, website or software localization project.
About us
Quick and reliable translations by professionals for professionals
PoliLingua is an interpretation and translation service that involves translating content from one language to another. We specialize in translation in such fields as Legal and Law, Life Sciences Technical & Manufacturing, Publishing & Media Translation Services, IT & Software, Retail, Game Localization, Government, Hospitality, Energy, Automotive and any other sector. We translate any documents from/into over 100 languages (English, French, Spanish, German, etc.).
8000 + native translators
4500 + projects a year
320 language pairs
Our services
Localization
According to the European Commission, 82% of customers are less likely to purchase products or services online if the website is not in their native language. Optimize your international customer base by ensuring that your documentation is translated into the reader's native language and culturally appropriate.
Multimedia and Web
Once you have invested time and money in multimedia technologies, it is important that your customers around the world understand the message. Besides web applications, we have localized other media including interactive software, video files, audio files, marketing communications, learning applications, video games, animations, and IVR scripts.
Website translation
We translate websites, optimize foreign-language pay-per-click ads, and develop foreign-language search engine optimization strategies for businesses of all sizes and in any industry. Our experienced team can also help you translate applications. According to a survey, this generates an increase in downloads and revenue of up to 120% and 25%, respectively.
Transcription and audio recording
PoliLingua offers a wide range of services for transcribing audio files into text files, including transcription directly into the target language and with translation solutions. With the help of dubbing professionals working in their native language, we also offer a wide range of dubbing and audio recording services, including call center scripts, audiobooks, and travel guides.
Document translation
Whether you need to publish a multilingual brochure, translate contracts for several parties, or prepare user manuals for an international market, PoliLingua can help you achieve your goals. With the help of the team of our professional translators who specialize in the relevant field, we provide accurate and high-quality translations according to your specifications and deadlines.
Languages
We provide 100 language solutions from our network of qualified native translators. Whether you’re looking for Spanish, Russian, or Japanese professional translation, we will find the right translator for your project.
French Translations
-
1,328 Professional French translators
-
9,292,300 French words translated
-
1,873 French translation projects
Spanish Translations
-
1,328 Professional French translators
-
9,292,300 French words translated
-
1,873 French translation projects
Italian Translations
-
1,328 Professional French translators
-
9,292,300 French words translated
-
1,873 French translation projects
German Translations
-
1,328 Professional French translators
-
9,292,300 French words translated
-
1,873 French translation projects
Portuguese Translations
-
1,328 Professional French translators
-
9,292,300 French words translated
-
1,873 French translation projects
Chinese Translations
-
1,328 Professional French translators
-
9,292,300 French words translated
-
1,873 French translation projects
FAQ
-
How is the price of language translation services defined?
The price of translation services is defined based on the following criteria:
- the language combination;
- the format of the original document;
- the subject and size (number of words) of the project;
- the desired turnaround time.
And if the translator uses a translation aid or translation memory, they can add a terminology bank and other reference materials to ensure consistency with the client's documents.
Several other factors influence the price of a translation service. For example, if you have been working with the same translator for a long time, the translator can deduce the passages they have already translated in your previous texts as well as repetitions, if there are many of them. -
Why do you need a certified document translation?
First thing’s first. You need to know which country will receive the paperwork. Since all countries are different, their laws and rules are different too. A certified translation in one country could be good enough for another, but not so good for the third one. For example, if you are from the United States and you do your paperwork for the United Kingdom, you need your translation to be certified by a UK sworn translator (the one sworn under the UK court). -
Is PoliLingua an accredited Translation & Interpreting Agency?
PoliLingua was founded in November 2002. Early on it was a translation service provider that had gradually expanded into localization, transcription, voice-over, subtitling, and multilingual content creation.
Back then, clients used the PoliLingua translation module only, but with the development of other departments that work with other types of translation, clients sought to benefit from integrating our services into the overall package.
We operate from London, UK and Chisinau, Moldova with representations in Berlin, Paris, Milan, and Madrid.
We work only with native professional linguists with experience in a particular field of knowledge, including the habitual and professional terminology.
We know how important it is to convey your ideas seamlessly, and we make sure it is both translated and localized carefully and accurately.
The professional translations we provide include, but do not limit to:- Translation
- Interpreting
- Transcreation
- Transcription
- Localization
- Subtitling
- Voice-over
- DTP
- Speech data collection
- Content creation
-
Why choose us amongst other leading translation agencies?
PoliLingua is all about fast and accurate translation process regardless of the industry your company is in. Our vast network of professional translators and interpreters enables us to achieve high-quality output with a quick turnaround. The more we work with our clients, the better we know them and their requirements and the quicker they get the desired result. -
What's the unique type of language translation services?
For almost 20 years, PoliLingua has been helping businesses break down the language barrier to communicate with their customers, employees, and partners and give customer profiles a new international reach.
Speaking the language of your clients and partners, and understanding cultural subtleties makes all the difference. Many medical, government and commercial organizations have trusted PoliLingua to be their language partner with professional and cost-effective language services.
Since 2001, we have been listening to the needs of our clients, designing and developing new solutions to ensure that language never stands in the way of winning or keeping customers, or entering a new market.
We develop quality language solutions that meet the needs of organizations through essential services that impact health, wealth, trade, and fundamental rights. No other language services provider can match our expertise.
Are the projects treated with pragmatism and professionalism?
Our many years of experience and consultative approach set us apart from other service providers in the translation industry. Since day one, we have been working with any company of any size in the public or private sector, including legal, medical, marketing, financial - the list goes on.
Whether your project involves the translation of a simple text, a complex multi-platform localization approach, a multilingual email management translation solution, or just a message chain you receive to your email address, our team can help you complete your projects on time.
Our services
Document translation
Whether you need to publish a multilingual brochure, translate contracts for several parties, or prepare user manuals for an international market, PoliLingua can help you achieve your goals. With the help of the team of our professional translators who specialize in the relevant field, we provide accurate and high-quality translations according to your specifications and deadlines.
Localization
According to the European Commission, 82% of customers are less likely to purchase products or services online if the website is not in their native language. Optimize your international customer base by ensuring that your documentation is translated into the reader's native language and culturally appropriate.
Multimedia and Web
Once you have invested time and money in multimedia technologies, it is important that your customers around the world understand the message. Besides web applications, we have localized other media including interactive software, video files, audio files, marketing communications, learning applications, video games, animations, and IVR scripts.
Website translation
We translate websites, optimize foreign-language pay-per-click ads, and develop foreign-language search engine optimization strategies for businesses of all sizes and in any industry. Our experienced team can also help you translate applications. According to a survey, this generates an increase in downloads and revenue of up to 120% and 25%, respectively.
Transcription and audio recording
PoliLingua offers a wide range of services for transcribing audio files into text files, including transcription directly into the target language and with translation solutions. With the help of dubbing professionals working in their native language, we also offer a wide range of dubbing and audio recording services, including call center scripts, audiobooks, and travel guides.
See all available languages
We provide 100 language solutions from our network of qualified native translators. Whether you’re looking for Spanish, Russian, or Japanese professional translation, we will find the right translator for your project.
Get in touch with our office now to get a free quote for our fast, accurate translation services
Email or call us, and follow us on Facebook, Twitter, and LinkedIn


ASLR is Adress Space Layout Randomization. ASLR randomizes the base addresses of loaded applications and DLLs. This means that you CANNOT just jump to shellcode addresses because the address space will be randomized on execution. There is a possibility to bruteforce (run the program enough times until you hit the address) or you have to calculate the address on the fly somehow.
Linux kernel 2.6.8 by default doesn't have ASRL (ASLR got added into the Linux kernel by default from 2.6.12 onwards), therefore the attacker doesn't have to worry about ASLR on older kernels (typically)
In linux, ASLR is typically set in proc/sys/kernel/randomize_va_space with value of 1. You can turn it off if you have permissions:
# echo 0 > /proc/sys/kernel/randomize_va_space
You can set /proc/sys/kernel/randomize_va_space with a value of 2 to force it on for everything.
# echo 2 > /proc/sys/kernel/randomize_va_space
value meanings:
0: ASLR disabled
1: ASLR (stack, virtual dynamic shared object page, and shared memory regions)
2: ASLR (1 + shared data segments as well)
You can also use ldd to help identify if ASLR is active
# ldd <binary> | grep libc
If the address that is returned changes with each invocation of ldd, then ASLR is enabeld


One area in software development that appears to have suffered from the malaise of the Cargo Cult [1] is the use of branching within the version control system. The decision to use, or avoid, branches during the development of a software product sometimes seems to be made based on what the “cool companies” are doing rather than what is suitable for the project and team itself.
What is often misunderstood about the whole affair is that it is not necessarily the branching strategy that allows these cool companies to deliver reliable software more frequently, but the other practices they use to support their entire process, such as automated testing, pair programming, code reviews, etc. These, along with a supportive organizational structure mean that less reliance needs to be made on the use of code branches to mitigate the risks that would otherwise exist.
This article describes the three main types of branching strategy and the forces that commonly dictate their use. From there it should be possible to understand how the problems inherent with branches themselves might be avoided and what it takes to live without them in some circumstances.
Branches are lines, in the genealogy sense, of product development that reflect an evolution of the codebase in a way that is consistent for a given set of constraints. In essence each branch has a policy [2] associated with it that dictates what types of change (commit) are acceptable into that codeline. When there is an “impedance mismatch” [3] between the code change and the policy, a branch may then be created to form a new codeline with a compatible policy.
All this talk of “forces” and “policies” is just posh speak for the various risks and mitigating techniques that we use when developing software. For example a common risk is making a change that breaks the product in a serious way thereby causing disruption to the entire team. One way of reducing the likelihood of that occurring is to ensure the code change is formally reviewed before being integrated. That in turn implies that the change must either be left hanging around in the developer’s working copy until that process occurs or committed to a separate branch for review later. In the former case the developer is then blocked, whilst in the latter you start accruing features that aren’t properly integrated. Neither of these options should sound very appealing and so perhaps it’s the development process that needs reviewing instead.
Branching is generally cheap, both in terms of version control system (VCS) resources and time spent by the developer in its creation. This is due to the use of immutability within the VCS storage engine which allows it to model a branch as a set of deltas on top of a fixed baseline.
Whilst the branch creation is easy, keeping it up-to-date (forward integration) and/or integrating our changes later (reverse integration) can be far more expensive. It’s somewhat ironic that we talk about “branching” strategies and not “merging” strategies because it’s the latter aspect we’re usually most interested in optimising. Merge Debt is a term that has sprung up in recent times to describe the ever increasing cost that can result from working in isolation on a branch without synchronising yourself with your surroundings.
Improvements in tooling have certainly made merging two text-based files slightly easier and there are new tools that try and understand the “meaning” of a code change at a language level to further reduce the need for manual intervention. Of course even these cannot help when there are semantic conflicts (syntactically correct changes that just do the wrong thing) [4]. And sadly binary files are still a handful. Refactoring can also be a major source of merge headaches when the physical structure of the codebase changes underneath you; this is compounded by the common practice of giving the folders and files the same names as the namespaces and classes.
As we shall see in the following sections, branches are essentially graded by their level of stability, or degree of risk. Consequently the preferable direction for any merging is from the more stable into the more volatile on the assumption that tried-and-tested is less risky. The reason “cherry pick” merges [5] get such a bad name is because they usually go against this advice – they are often used to pull a single feature “up” from a more volatile branch. This carries with it the risk of having to drag in dependent changes or to try and divorce the desired change from its dependents without breaking anything else.
Before embarking on a full discussion of the main branching strategies we need to clear up some terminology differences that often come up as a result of the different naming conventions used by various VCS products.
Although there are three basic strategies, there are only two real types of branch – integration and private. Either you share the branch with others and collaborate or you own the branch and are solely responsible for its upkeep. It’s when you share the branch with others that the sparks really start to fly and so these tend to be minimised.
For small teams there is usually only a single major integration branch and this often goes by the name of main, trunk or master. Sometimes this is known as the development branch to distinguish it from one of the other more specialised kinds. Either way it’s expected that this will be the default branch where the majority of the integration will finally occur.
In larger organisations with much bigger teams there might be many integration branches for the same product, with perhaps one integration branch per project. At this scale the integration branch provides a point of isolation for the entire project and may spin off its own child branches. Multiple integration branches come with additional overhead, but that may well be less than the contention generated by a large team trying to share a single integration branch. If the project itself carries a large degree of uncertainty or cannot be delivered piecemeal then this project-level isolation can be more beneficial in the long run.
Back in the days before VCS products supported the ability to branch you essentially had only one branch where all change took place. As the development process reached a point where the product was readying itself for a formal release, a code freeze was often put in place to reduce the changes to only those directly required to get the product out of the door. For those developers not directly working on “finishing” the product they had to find other work to do, or find other ways to manage any code changes destined for later releases.
Once branching became available a common answer to this problem was to branch the codebase at a suitable moment so that work could continue on the next version of the product in parallel with the efforts to the stabilise the impending release. The codeline policy for a release branch is therefore based around making very few, well reviewed, well tested changes that should resolve outstanding issues without creating any further mess. As the release date approaches finding the time to continually test and re-test the entire product after every change can become much harder and therefore more time is often spent up front attempting to decide whether further change is even really desirable.
The branch is often not “cut” from the development line at an arbitrary point in time – there will probably have been a reduction in high-risk changes leading up to the branch point so as to minimise the need to try and revert a complex feature at the last minute. By the time the release branch is ready to be created it should be anticipated that future additional changes will be kept to a bare minimum. This implies that during project planning the high-risk items are front-loaded to ensure they are given the longest time to “bed in”, i.e. you don’t upgrade compilers the day before a release.
The most extreme form of a product release is probably a patch, or hotfix. Time is usually the most critical aspect and so it demands that any change be completed in total isolation as this allows it to be done with the highest degree of confidence that there are no other untoward side-effects. This kind of release branch is usually created directly from a revision label as that should be the most direct way to identify the part of the product’s entire history that corresponds to the product version needing remediation. Whereas a branch is an evolving codeline, a label (or tag) is a snapshot that annotates a single set of revisions as a specific milestone.
What should be apparent about this particular strategy is that it’s mostly about compensating for a lack of stability in the main development process. If you never have to worry about supporting multiple product versions, then in theory you can change your development process to avoid the need for formal release branches. By ensuring you have adequate automated feature and performance testing and a streamlined development pipeline you should be able to deliver directly from the main integration branch.
However, despite the development team’s best efforts at working hard to minimise the delays in getting a feature into production, there can still be other organizational problems that get in the way of delivery. Maybe there needs to be formal sign-off of each release, e.g. for regulatory purposes, or the QA cycle is out of your hands. In these cases the release branch acts more like a quarantine zone while the corporate cogs slowly turn.
From a merging perspective release branches are generally a low-maintenance affair. As already stated the most desirable merge direction is from the stable codebase and release branches changes should be about the most carefully crafted of them all. Due to each one usually being an isolated change with high importance they can be merged into any ongoing integration branches the moment it becomes practical instead of waiting until the end.
If you think of the main development branch as the equator then a feature branch is the polar opposite of a release branch. Where the codeline policy for a release branch is aimed at providing maximum stability through low-risk changes, a feature branch has a policy aimed at volatile, high-risk changes. Instead of protecting the release from unwanted side-effects we’re now protecting the main development pipeline from stalling for similar reasons.
The definition of “feature” could be as small as a simple bug fix made by a single developer right up to an entire project involving many developers (the aforementioned project-level integration branch). Other terms that are synonymous are “task branch” and “private branch”. One suggests a narrower focus for the changes whilst the other promotes the notion of a single developer working in isolation. Either way the separation allows the contributor(s) to make changes in a more ad-hoc fashion that suits their goal. As such they need not worry about breaking the build or even checking in code that doesn’t compile, if that’s how they need to work to be effective.
One common use for a feature branch is to investigate changes that are considered experimental in nature, sometimes called a spike [6]. This type of feature may well be discarded at the end of the investigation with the knowledge gained being the point of the exercise.  Many version control systems don’t handle file and folder renames very well and so this makes tracing the history across them hard. For example, during a period of heavy refactoring files (i.e. classes) may get renamed and moved around which causes their history to become detached. Even if the changes are reverted and the files return to their original names the history can still remain divorced as the VCS just sees some files deleted and others added.
In some cases the changes themselves may be inherently risky, but it may also be that the person making the changes might be the major source of risk. New team members always need some time getting up to speed with a new codebase no matter how experienced they are. However junior programmers will likely carry more risk than their more senior counterparts, therefore it might be preferable to keep their work at arms length until the level of confidence in their abilities (or the process itself adapts) to empower them to decide for themselves how a change should best be made.
Once again it should be fairly apparent that what can mitigate some uses of feature branches is having a better development process in the first place. With a good automated test suite, pair programming, code reviews, etc. the feedback loop that detects a change which could destabilise the team will be unearthed much quicker and so headed it off before it can escalate.
What makes feature branches distasteful to many though is the continual need to refresh it by merging up from the main integration branch. The longer you leave it before refreshing the more chance you have that the world has changed underneath you and you’ll have the merge from hell to attend to. If the team culture is to refactor relentlessly then this will likely have a significant bearing on how long you leave it before bringing your own branch back in sync.
Frequently merging up from the main integration branch is not just about resolving the textual conflicts in the source code though. It’s also about ensuring that your modifications are tested within the context of any surrounding changes to avoid the semantic conflicts described earlier. Whilst it might technically be possible to integrate your changes by just fixing any compiler warnings that occur in the final merge, you need to run the full set of smoke tests too (at a minimum) so that when you publish you have a high degree of confidence that your changes are sound.
There is a special term for the degenerate case of a single-commit feature branch – shelving. If there is a need to suddenly switch focus and there are already changes in flight that you aren’t ready to publish yet some VCS’s allow you to easily put them to one side until you’re ready to continue. This is usually implemented by creating a branch based on the revision of the working copy and then committing any outstanding changes. When it’s time to resume, the changes can be un-shelved by merging the temporary branch back into the working copy (assuming the ancestry allows it).
One alternative to shelving is to have multiple working folders all pointing at different branches. If you constantly have to switch between the development, release and production codebases for example it can be easier (and perhaps faster) to just switch working folders than to switch branches, especially now that disk space is so cheap.
The introduction of the Distributed Version Control System (DVCS) adds another dimension to the branching strategy because a developer’s machine no longer just holds a working set of changes, but an entire repository. Because it’s possible to make changes and commit them to a local repo the developer’s machine becomes a feature branch in its own right. It is still subject to the same issues in that upstream changes must be integrated frequently, but it can provide far more flexibility in the way those changes are then published because of the flexibility modern D-VCSs provide.
Back in the days before version control systems were clever enough to support multiple threads of change through branches there was just a single shared branch. This constraint in the tooling had an interesting side-effect that meant making changes had to be more carefully thought out.
Publishing a change that broke the build had different effects on different people. For some it meant that they kept everything locally for as long as possible and only committed once their feature was complete. Naturally this starts to get scary once you consider how unreliable hardware can be or what can go wrong every time you’re forced to update your working folder which would entail a merge. Corruption of uncommitted changes is entirely possible if you mess the merge up and have no backup to return to.
The other effect was that some developers learnt to break their work down into much more fine-grained tasks. In contrast they tried to find a way to commit more frequently but without making changes that had a high chance of screwing over the team. For example new features often involve some refactoring work to bring things into shape, the addition of some new code and the updating or removing of other sections. Through careful planning some of this work can often be done alongside other people’s changes without disturbing them, perhaps with some additional cost required to keep the world in check at all times. For instance, by definition, refactoring should not change the observable behaviour and so it must be possible to make those changes immediately (unanticipated performance problems notwithstanding).
This then is the premise behind using a single branch for development along with feature toggles to hide the functionality until it is ready for prime time. The notion of “always be ready to ship” [7] engenders an attitude of very small incremental change that continually edges the product forward. The upshot of this is that “value” can be delivered continually too because even the refactoring work has some value and that can go into production before the entire feature might be implemented.  The desire to increase collaboration and deliver more frequently will usually lead to the use feature toggles as a way of resolving the tension created by partially implemented stories.
This method of development does not come easily though, it demands some serious discipline. Given that every change is published to the team and the build server straight away means that there must be plenty of good practices in place to minimise the likelihood of a bug or performance problem creeping in unnoticed. The practices will probably include a large, mostly automated test suite along with some form of reviewing / pairing to ensure there are many “eyes” watching.
The way that the feature is “toggled” can vary depending on whether its activation will be static (compile time) or dynamic (run time). From a continuous testing point of view it makes far more sense to ensure any new feature is enabled dynamically otherwise there are more hoops to jump through to introduce it into the test suite. Doing it at runtime also helps facilitate A/B testing [8] which allows old and new features to run side-by-side for comparison.
The nature of the toggle varies depending
on what mechanisms are available, but either way the number of points in the
code where the toggle appears should be kept to an absolute minimum. For
example, instead of littering the code with #ifdef
style
pre-processor statements to elide the code from compilation it is preferable to
have a single conditional statement that enables the relevant code path:-
if
(isNewFeatureEnabled)
DoNewFeature();
The toggle could take the form of a menu
item in the UI, an entry in a configuration file, an #ifdef
compilation directive, a data file, an extra parameter in an HTTP request, a
property in a message, the use of REM
to comment in/out a
command in a batch file, etc. Whatever the choice its absence will generally
imply the old behaviour, with the new behaviour being the exception until it
goes live for good. At that point it will disappear once again.
One side-effect of working with feature toggles is that there might be a clean-up exercise required at the end if it gets pulled or if it supplants another feature – this will happen after go live and so needs to be planned in. During development there will also be periods of time where “unused code” exists in the production codebase because the feature hasn’t been fully implemented yet. Whilst it’s beneficial that others get early sight of the ongoing efforts they need to be sure not to delete what might seem to be “dead code”.
The motivation for not branching is effectively to avoid merging at all. That won’t happen, simply because you need to continually refresh your working folder and any update could require a merge. However, the likelihood that any conflicts will crop up should be greatly diminished. In particular “noisy” refactorings can be easier to co-ordinate because the changes can be made, pushed and pulled by others with the minimum of fuss.
The three core branching strategies are not in any way mutually exclusive. It’s perfectly acceptable to do, say, the majority of development on the main integration branch with occasional feature branches for truly risky tasks and release branches to avoid getting stalled due to bureaucracy (e.g. waiting for the Change Review Board to process the paperwork).
Historically a tool like Visual C++ cannot be silently upgraded. Its project and solution data files are tied to a specific version and must match the version of the tool being used by the programmer. In the past this has created problems for larger teams where you all cannot just migrate at the same time without some serious groundwork. Aside from the project data file problems, in C++ at least, there is also the problem of the source code itself being compatible with the new toolchain. Visual C++ used to default to the non-standard scoping rules for a “for” loop meaning that the loop variable could leak outside the loop and into lower scopes. Bringing the codebase in line with the ISO standard also meant source code changes to be handled too.
When I tackled this with a medium sized team that were working on separate projects on multiple integration branches I had use a combination of branching approaches as a big bang switchover was never going to work. Although the build and deployment process was somewhat arcane the fact that multiple streams already existed meant that the parallelisation aspect was going to be less painful.
As part of an initial spike I used a feature branch to investigate what I needed to upgrade the tooling and to see what the impact would be vis-à-vis source code changes. The end result of that were just some new build scripts to handle the tooling upgrade; everything else was ditched.
The next step was to bring as much of the existing codebase up to scratch by fixing the “for” loop scoping manually (where necessary) by inducing an extra scope (you just enclose the existing loop with another pair of braces). On one integration branch I upgraded the toolchain locally, fixed all the compiler errors and warnings, then reverted the toolchain upgrade, re-compiled with the current toolchain to verify backwards compatibility and finally committed just the source code changes. An email also went out too educating the other developers for the kinds of issues that might crop up in the future so that any new code would stand a better chance of being compatible at the final upgrade time.
Those code changes and the new upgrade scripts were then merged (cherry picked) into every integration branch so that each one could then be inspected and any new changes made since the original branch point occurred could made compatible too. At this point all the integration branches were in good shape and ready to migrate once we had ironed out the non-syntactic problems.
The next step was to verify that a build with the new toolchain worked at runtime too and so a new feature branch was taken from one of the integration branches which could be used to build and deploy the product for system testing. This allowed me to iron out any bugs in the code that only showed up with the new compiler behaviour and runtime libraries. Once fixed these changes could also be pushed across to the other integration branches so that all of the projects are now in a position to make the final switch.
My goal when doing this work was to avoid messing up any one project if at all possible. The uncertainty around the delivery schedule of each project meant that I didn’t know at the start which one was going to be the best to use to “bed in” the upgrade, so I made sure they were all candidates. Whilst it felt wasteful to continuously throw changes away (i.e. the upgraded project files) during the migration process, the painless way the final switchover was done probably meant more time was saved by my team mates in the long run.
In recent times one particular hybrid approach has sprung up that attempts to formalise the need to pass some review stage before the change can be accepted into the main codeline. This review process (the aforementioned gatekeeper) can either be done entirely automatically via a continuous integration server; or via some form of manual intervention after the build server has given the change the green light.
This style of workflow is the opposite of the “no branching” approach because it relies on not letting anyone commit directly to the integration branch. Instead each developer gets their own feature branch into which they make their changes. Any time a developer’s branch has changed the continuous integration server will attempt to merge it with the integration branch, then build and run the test suite.
If that process succeeds and an automated gatekeeper is in play then the merge is accepted and the main branch is advanced. If a manual gatekeeper is involved, perhaps to review the change too they can perform that knowing it has already passed all the tests which helps minimise wasting time on reviewing low quality changes. If the change fails at any stage, such as the merge, build or test run then the developer will need to resolve the issue before going around the loop again.
Whilst this has the benefit of ensuring the main development branch is always in a consistent state, build-wise, it does suffer from the same afflictions as any other feature branch – a need to continuing merge up from the integration branch. That said, where the no branching approach relies heavily on diligence by the programmer these workflows look to leverage the tooling in the continuous integration server to try and minimise the overhead. For example, just as they can automatically merge a feature branch to the integration branch on a successful build, they can also merge any changes from the integration branch back out to any feature branches when updated by the rest of the team. The net effect is that programmers can spend less time worrying about “breaking the build” because they never contribute to it unless their changes are already known to be coherent.
This style of workflow could also be combined with feature toggles to aid in delivering functionality in a piecemeal fashion.
The goal of this article was to distil the folklore surrounding branching strategies down into the three key patterns – no branching, branching for a feature and branching for a release. We identified the policies that commonly drive the choice of strategy and the forces, often organisational in nature, that can push us in that direction. Finally we looked at how and when it might be suitable to combine them rather than blindly try to stick to the same strategy all the time, and how tooling is beginning to help reduce some of the overhead.
A big thumbs-up from me goes to
[1] http://en.wikipedia.org/wiki/Cargo_cult_programming
[2] Software Configuration Management Patterns, Stephen P. Berczuk with Brad Appleton, Chapter 12 – Codeline Policy
[3] http://c2.com/cgi/wiki?ImpedanceMismatch
[4] http://martinfowler.com/bliki/SemanticConflict.html
[5] http://c2.com/cgi/wiki?CherryPicking
[6] http://www.extremeprogramming.org/rules/spike.html
[7] http://c2.com/cgi/wiki?AlwaysBeReadyToShip
[8] http://en.wikipedia.org/wiki/A/B_testing
19 May 2014
Bio
Chris is a freelance developer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros; these days it’s C++ and C#. He also commentates on the Godmanchester duck race and can be contacted via<EMAIL_ADDRESS>or @chrisoldwood.


The search result is framed below. This upper control frame is larger than normal to allow for these tutorial messages; it would normally be about half the vertical size to give greater focal attention to the displayed result.
You can select an application from your list of purchased applications to run on the result below. These have not been implemented, though the BibTexExport application does demonstrate with a boilerplate citation what might be done on application selection.
Also note the Remove Frame link to leave Open Science and browse starting from the result.
The tutorial continues by viewing the preferences page, linked in the upper right as Preferences.


AESEncoder()
Syntax
Result = AESEncoder(*Input, *Output, Size, *Key, Bits, *InitializationVector [, Mode])Description
Encodes the specified input buffer using the AES algorithm into the output buffer.
Parameters
*Input The input buffer with the plain data. *Output The output buffer which will receive the encoded data. It has to be different than the input buffer. Size The amount of bytes to encode. It has to be at least 16 bytes. To encode something smaller, padding has to be added before the encoding. *Key A buffer containing the key for encoding. Its size depends of the 'Bits' parameter: l6 bytes for 128-bit encryption, 24 bytes for 192 bit and 32 bytes for 256-bit. Bits The size of the key used by the ciphering. Valid values are 128, 192 and 256. *InitializationVector The InitializationVector is a random data block, used to initialize the ciphering to avoid breach in decoding (only needed when using the #PB_Cipher_CBC mode). The initialization vector is always 16 bytes long. Mode (optional) This can be one of the following value: #PB_Cipher_CBC: Default mode of encoding (Cipher Block Chaining). Needs an '*InitializationVector'. Recommended as more secure than ECB mode. #PB_Cipher_ECB: Alternative mode (Electronic CodeBook). It doesn't use a random value or chaining (each block is ciphered independently) making it less strong the CBC.
Return value
Returns nonzero if the encoding was successful, zero otherwise.
Remarks
AES is an industry class cipher algorithm and is good balanced between speed and security. Here is the Wikipedia introduction about AES: 'In cryptography, the Advanced Encryption Standard (AES) is an encryption standard adopted by the U.S. government. The standard comprises three block ciphers, AES-128, AES-192 and AES-256, adopted from a larger collection originally published as Rijndael. Each AES cipher has a 128-bit block size, with key sizes of 128, 192 and 256-bit, respectively. The AES ciphers have been analyzed extensively and are now used worldwide.'
PureBasic uses a RFC compliant implementation of AES. More information can be found in the RFC 3602: http://www.ietf.org/rfc/rfc3602.txt.
Example: CBC
; Should be compiled in ascii mode ; String$ = "Hello this is a test for AES" *CipheredString = AllocateMemory(Len(String$)+1) ; Space for the string and its *DecipheredString = AllocateMemory(Len(String$)+1) ; null terminating character (ASCII mode) If AESEncoder(@String$, *CipheredString, Len(String$), ?Key, 128, ?InitializationVector) Debug "Ciphered: "+PeekS(*CipheredString) AESDecoder(*CipheredString, *DecipheredString, Len(String$), ?Key, 128, ?InitializationVector) Debug "Deciphered: "+PeekS(*DecipheredString) EndIf DataSection Key: Data.b $06, $a9, $21, $40, $36, $b8, $a1, $5b, $51, $2e, $03, $d5, $34, $12, $00, $06 InitializationVector: Data.b $3d, $af, $ba, $42, $9d, $9e, $b4, $30, $b4, $22, $da, $80, $2c, $9f, $ac, $41 EndDataSection
Example: ECB
; Should be compiled in ascii mode ; String$ = "Hello this is a test for AES" *CipheredString = AllocateMemory(Len(String$)+1) ; Space for the string and its *DecipheredString = AllocateMemory(Len(String$)+1) ; null terminating character (ASCII mode) If AESEncoder(@String$, *CipheredString, Len(String$), ?Key, 128, 0, #PB_Cipher_ECB) Debug "Ciphered: "+PeekS(*CipheredString) AESDecoder(*CipheredString, *DecipheredString, Len(String$), ?Key, 128, 0, #PB_Cipher_ECB) Debug "Deciphered: "+PeekS(*DecipheredString) EndIf DataSection Key: Data.b $06, $a9, $21, $40, $36, $b8, $a1, $5b, $51, $2e, $03, $d5, $34, $12, $00, $06 EndDataSection
See Also
AESDecoder(), StartAESCipher()
Supported OS
All


☰
×
Google Search
Image Search
Private Search
Job Search
Bing Search
Copyright Free Search
Private Google Search
Wiki Search
Forum Search
Slide Search
Blog Search
Amazon Product Search
News Search
Youtube Search
Darkweb Search
Github Search
People Search
Movie Search
H
u
m
b
l
e
Find pages with...
All these words:
This exact word or phrase:
Any of these words:
None of these words:
Made with ❤ By
Tywary


Plugin works ok
Native plugin is not installed, download and install native plugin from
here
Native plugin is outdated, download and install latest update from
here
New version of plugin is available, download and install latest update from
here
Plugin is not supported on your OS, it is supported only on Windows platform at the momment.


Google Code offered in: English - Español - 日本語 - 한국어 - Português - Pусский - 中文(简体) - 中文(繁體)
GWT's network operations are all asynchronous, or non-blocking. That is, they return immediately as soon as called, and require the user to use a callback method to handle the results when they are eventually returned from the server. Though in some cases asynchronous operations are less convenient to use than synchronous operations, GWT does not provide synchronous operations.
The reason is that most browsers' JavaScript engines are single-threaded. As a result, blocking on a call to XMLHTTPRequest also blocks the UI thread, making the browser appear to freeze for the duration of the connection to the server. Some browsers provide a way around this, but there is no universal solution. GWT does not implement a synchronous network connection because to do so would be to introduce a feature that does not work on all browsers, violating GWT's commitment to no-compromise, cross-browser AJAX. It would also introduce complexity for developers, who would have to maintain two different versions of their communications code in order to handle all browsers.
Modern browsers implement a security model known as the Same Origin Policy (SOP). Conceptually, it is very simple, but the limitations it applies to JavaScript applications can be quite subtle.
Simply stated, the SOP states that JavaScript code running on a web page may not interact with any resource not originating from the same web site. The reason this security policy exists is to prevent malicious web coders from creating pages that steal web users' information or compromise their privacy. While very necessary, this policy also has the side effect of making web developers' lives difficult.
It's important to note that the SOP issues described below are not specific to GWT; they are true of any AJAX application or framework. This FAQ simply details the specific ways in which GWT is affected by this universal limitation.
When you compile a GWT application, it produces JavaScript code and HTML files. Because a GWT application is broken up into multiple files, the browser will make multiple requests from the HTTP server to fetch all the pieces. Previous to GWT 1.4, this meant that all the GWT files must live on the same web server as the page which launches the GWT application so as not to break the SOP. In GWT 1.4 and later, this is no longer an issue thanks to the new cross-site script inclusion bootstrap process mode.
Typically, the bootstrap process will load the GWT application files from the same web server that is serving the HTML host page. That is, supposing the host HTML file was located at http://mydomain.com/index.html, the GWT application files would also be in the same directory (or a subdirectory) as the index.html file. To load the GWT application, the <module>.nocache.js file would be bootstrapped by having the index.html file include a <script> tag referencing the <module>.nocache.js file. This is the standard bootstrap process to load a GWT application. The <script> tag that needs to be included in the main host HTML page is shown below:
<script language="JavaScript" src="http://mydomain.com/<module>.nocache.js"></script>
However, many organizations setup their deployment platform in such a way that their main host HTML page is served up from http://mydomain.com/, but any other resources such as images and JavaScript files are served up from a separate static server under http://static.mydomain.com/. In older versions of GWT, this configuration would not be possible as the SOP prevented the GWT bootstrap process from allowing script from files that were added from a different server to access the iframe in the main host HTML page. As of GWT 1.5, the bootstrap model now provides support for this kind of server configuration via the cross-site linker (xs-linker).
When using the cross-site linker the compiler will still generate a <module>.nocache.js that you will want to reference within your index.html. The difference though, is that the <module>.nocache.js produced by the cross-site linker will link in a cache.js file for each of your permutations rather than a cache.html file.
To enable the cross-site linking simply add the following to your <module>.gwt.xml and include a reference to your <module>.nocache.js in your index.html as you normally would.
<add-linker name="xs"/>
For more details on the GWT bootstrap process, see "What's with all the cache/nocache stuff and weird filenames?"
The second area where the SOP is most likely to affect GWT users is the use of XMLHTTPRequest -- the heart of AJAX. The SOP limits the XMLHTTPRequest browser call to URLs on the same server from which the host page was loaded. This means that it is impossible to make any kind of AJAX-style request to a different site than the one from which the page was loaded. For example, you might want to have your GWT application served up from http://pages.mydomain.com/ but have it make requests for data to http://data.mydomain.com/, or even a different port on the same server, such as http://pages.mydomain.com:8888/. Unfortunately, both these scenarios are impossible, prevented by the SOP.
This limitation affects all forms of calls to the server, whether JSON, XML-RPC, or GWT's own RPC library. Generally, you must either run your CGI environment on the same server as the GWT application, or implement a more sophisticated solution such as round-robin DNS load balancing or a reverse-proxy mechanism for your application's CGI calls.
In certain cases, it is possible to work around this limitation. For an example, see "How can I dynamically fetch JSON feeds from other web domains?"
The SOP applies to all GWT applications, whether running in web (compiled) mode on a web server, or in development mode. For example, it is perfectly possible to launch a GWT application from a file:// URL pointing to a file on your local computer. Though GWT will run in this case, it will be unable to access any resources from a web server because it will be constrained to the "site" from which it was loaded--your computer's filesystem.
This can cause problems if you are attempting to develop a GWT application that uses server-side technologies not supported by the GWT development mode, such as EJBs or Python code. In such cases, you can use the -noserver argument for development mode to launch your GWT application from the server technology of your choice. For more information, see "How do I use my own server in development mode instead of GWT's built-in Jetty instance?" Even if you choose to use this feature, however, remember that the SOP still applies.
The heart of AJAX is making data read/write calls to a server from the JavaScript application running in the browser. GWT is "RPC agnostic" and has no particular requirements about what protocol is used to issue RPC requests, or even what language the server code is written in. Although GWT provides a library of classes that makes the RPC communications with a J2EE server extremely easy, you are not required to use them. Instead you can build custom HTTP requests to retrieve, for example, JSON or XML-formatted data.
To communicate with your server from the browser without using GWT RPC:
You must use an asynchronous server connection.
GWT provides a library to largely (though not completely) automate the steps necessary to communicate with the server via HTTP requests. GWT application developers should use the RequestBuilder class and other classes in the com.google.gwt.http.client.html package, which contains a clean asynchronous server request callback implementation.
Note:
New users frequently notice the com.google.gwt.user.client.HTTPRequest class and attempt to use it.
However, the HTTPRequest class is deprecated and will be removed at some point in the future.
You should definitely use RequestBuilder
instead.
If you are attempting to use the RequestBuilder class and are having problems, first check your module XML file to make sure that the HTTP module is inherited, as follows:
<inherits name="com.google.gwt.http.HTTP"/>
The GWT RPC system does support the use of java.io.Serializable, however only under a certain condition.
Previous to 1.4, the GWT RPC mechanism used an "IsSerializable" marker interface for denoting classes that can be serialized. Many users expressed the wish to reuse code with GWT that they have already written that used the standard java.io.Serializable marker interface. Since both interfaces are empty marker interfaces, there is no technical reason why GWT's RPC mechanism could not use the standard java.io.Serializable. However, there are good reasons to choose not to do so:
While each of the points above still hold, the GWT Team felt that the community was generally aware of these issues but preferred the convenience of being able to use the standard java.io.Serializable interface rather than to have their classes implement the isSerializable marker interface, although both marker interfaces to denote serializable classes are supported in GWT 1.4 and later. Considering this, the GWT Team made changes to the GWT RPC system to support the use of java.io.Serializable for data transfer objects (commonly referred to as DTOs) that would be transferred over the wire. However, there is one condition to enable support for java.io.Serializable in the new GWT RPC system.
RPC now generates a serialization policy file during GWT compilation. The serialization policy file contains a whitelist of allowed types which may be serialized. Its name is a strong hash name followed by .gwt.rpc. In order to enable support for java.io.Serializable, the types that your application will send over the wire must be included in the serialization policy whitelist. Also, the serialization policy file must be deployed to your web server as a public resource, accessible from a RemoteServiceServlet via ServletContext.getResource(). If it is not deployed properly, RPC will run in 1.3.3 compatibility mode and refuse to serialize types implementing java.io.Serializable.
Another important point to note is that none of the classes that implement java.io.Serializable in the full Java JRE implement java.io.Serializable in GWT's emulated JRE. What this means is that types that implement java.io.Serializable in the JRE like Throwable, or StackTraceElement won't be able to transfer across the wire through GWT RPC since the client won't be able to serialize/deserialize them. However, this isn't an issue for other types like String, Number, etc... that don't implement java.io.Serializable in the emulated JRE but have custom field serializers so that they can be properly serialized.
These differences between types that implement java.io.Serializable in the real and emulated JREs may be reconciled in a future version of GWT, but for the time this is an important point to keep in mind if your application uses GWT RPC.
Like all AJAX tools, GWT's HTTP client and RPC libraries are restricted to only accessing data from the same site where your application was loaded, due to the browser Same Origin Policy. If you are using JSON, you can work around this limitation using a
<script>
tag. To accomplish this, though, you must resort to using DOM manipulation methods to inject the tag into your host page dynamically.
First, you need an external JSON service which can invoke user defined callback functions with the JSON data as argument. An example of such a service is GData's "alt=json-in-script&callback=myCallback" support. Then, you can generate a bridge method, which will be used to invoke a GWT JSON callback handler.
Here is an example:
package mypackage; public class MyJSONUtility { interface JSONHandler { public void handleJSON(JavaScriptObject obj); } public static native void makeJSONRequest(String url, JSONHandler handler) /*-{ $wnd.jsonCallback = function(jsonObj) { @mypackage.MyJSONUtility::dispatchJSON(Lcom/google/gwt/core/client/JavaScriptObject;Lcom/google/gwt/sample/client/JsonTestApp$JSONHandler;)(jsonObj, handler); } // create SCRIPT tag, and set SRC attribute equal to JSON feed URL + callback function name var script = $wnd.document.createElement("script"); script.setAttribute("src", url+"jsonCallback"); script.setAttribute("type", "text/javascript"); $wnd.document.getElementsByTagName("head")[0].appendChild(script); }-*/; public static void dispatchJSON(JavaScriptObject jsonObj, JSONHandler handler) { handler.handleJSON(jsonObj); } }
You can then implement the JSONHandler interface as you choose, and call
MyJSONUtility.makeJSONRequest( "http://www.google.com/calendar/feeds/developer-calendar@google.com/public/full?alt=json-in-script&callback=", myHandlerInstance);
Of course, the above example doesn't handle multiple concurrent requests. For that, you need an array of bridge methods; you would access them during callbacks using syntax similar to
jsonCallbacks[requestNumber].
If the external feed doesn't support callback function names using array syntax, you can generate uniquely named bridge methods like jsonCallback1, jsonCallback2, etc. Also, don't forget to cleanup in the bridge function after it's been called, such as removing the SCRIPT node that's been added to the DOM, and deleting the bridge method, since they are no longer used once you have the result.
GWT 1.5 introduced Overlay Types for interoperating directly with native JavaScriptObjects without the need for any wrapper objects.
Please see older documentation's FAQ.


Unilog.
Putting you in control
Home
Registration
Admin Portal
You have been logged out
There was an error, please try again
Unilog Academic Verification Service - Login Portal


Protect the farm: Team Liquid defends Frenzy Farm at all costs
by Jimmy RussoYesterday, we saw one of the best storylines of the Fortnite Champion Series: Protect the Farm. Team Liquid did everything in their power to establish their dominance over Frenzy Farm.
The Fortnite Champion Series Week 4 finals were one of the best times to be a fan of competitive Fortnite. We saw Tfue’s team implode as the streamer lashed-out at another pro player for contesting Steamy Stacks.
Towards the middle of the map, there was a massive battle over Frenzy Farm that spanned several matches. Pro player YourFellowArab and his squad made it clear that they would be contesting the Liquid team of Vivid, Chap, 72hrs, and CizLucky.
The rivalry started as soon as the competition did. CizLucky and Chap immediately contested Arab, who took them down with a burst AR.
As you can imagine, Arab shouted and boasted after winning the fight. He and his team let Vivid and 72hrs get away but went on to win their first match.
Things went quite a bit differently after the first game.
This fight didn’t stop there, though. Arab and his squad gave up on contesting the Liquid boys, but ‘Lucky Liquid’ wasn’t done with them. The latter squad saw their arch enemies rotating mid-game, and did all they could to hunt them down and kill them.
Chap, 72hrs, Vivid, and CizLucky have already qualified for the FNCS Grand Finals. They don’t need to score any more points, so they threw their final match to grief YourFellowArab and make sure that his team never returned to ‘Frenzy Clout Farm.’
The whole back-and-forth was incredibly entertaining. It was all in-game and fair, despite allegations that each team pulled up the others’ streams to gain an advantage.
- Read More:
There’s no evidence of this on either side – at least while the teams were still playing. Arab pulled up a Liquid stream at one point after he died but never relayed any information to his squad about where the opponents were heading.
By most accounts, this is an entertaining and controversy-free display of competitive Fortnite. Arab and his squad wanted the smoke and ‘Lucky Liquid’ wanted to make sure that no one contested them in the Grand Finals.
The Liquid boys made an example out of the contesting team: “This is what happens if you come after us.” They went a step further and taught Arab and company a lesson by griefing them in the later matches.
The whole thing was extremely entertaining to watch. I suggest pulling up a VOD or watching a highlight video if you haven’t seen it. Good content all around.
GG’s only.


|
We miss you, *|FNAME|*! Save 15% next time at checkout.
|
|
|
|
|
Answer 2 Questions for 15% Off Your Next Purchase.
|
To celebrate the launch of our new online shop, The Pool Table Store is offering a limited-time 15% off coupon if you answer two
questions (click below).
Valid for all of 2019 - Get it before it's gone! We won't clutter your inbox, we promise. We look forward to hearing your responses - and stay tuned for an announcement in Used Pool Tables.
|
|
|
|
|
|
|
|
|


http://www.patrickkeisler.com/2012/11/how-to-use-xpdirtree-to-list-all-files.html
http://www.patrickkeisler.com/2012/12/how-to-use-xpdirtree-to-list-all-files-part2.html
In order to do that, we'll use another undocumented extended stored procedure; master.sys.xp_dirtree. This stored procedure will display a list of every folder, every subfolder, and every file for path you give it.
Xp_dirtree has three parameters:
directory - This is the directory you pass when you call the stored procedure; for example 'D:\Backup'.
depth - This tells the stored procedure how many subfolder levels to display. The default of 0 will display all subfolders.
file - This will either display files as well as each folder. The default of 0 will not display any files.
This stored procedure also can accept UNC paths (\\Server\Folder) to get a list of files and subfolders from a network drive.


The insurer
Are you sure that you want to delete this element?
{{data.name}}: {{data.price}}
Some text


Contact name
City
Country
Is Promoted
Maria Anders
Berlin
Germany
Anna Trujillo
México D.F.
Mexico
Antonio Morero
México D.F.
Mexico
Thomas Hardy
London
UK


Contact details
Phone:<PHONE_NUMBER>
Email:
<EMAIL_ADDRESS>linkedin
Your Name:
Email:
Passward:
Date of Birth:
Photo:
Your message:
Do want to signup to the Email List ?


{% extends "inner_base.html" %} {% block title %}Welcome Inside!{% endblock %} {% block header %}Welcome to Flask!{% endblock %} {% block main %}
This is a template for a simple marketing or informational website. It includes a large callout called the hero unit and three supporting pieces of content. Use it as a starting point to create something more unique.
Current user: {{ session['username'] }}
Switch: {{ switch }}


Change your email address on {{ host }}
You has requested a email address changing for your {{ host }} account. Follow the link below to do this:
{{ link }}


--- layout: post title: Episode 117 | Joyce Akiko - Life On Your Terms link: http://traffic.libsyn.com/developeronfire/DeveloperOnFire-117-JoyceAkiko.mp3 length: 34318218 speaker: Dave Rael duration: '00:32:21' subtitle: 'Developer On Fire: Joyce Akiko' guest_name: Joyce Akiko image: /assets/images/JoyceAkiko.jpg guest_blog: http://www.joyceakiko.com/ guest_twitter: joyceakiko episode_number: 117 book_recommendations: - { url: "http://www.amazon.com/dp/193594486X/?tag=devonfir-20", title: "The Slight Edge: Turning Simple Disciplines Into Massive Success", author: "Jeff Olson"} - { url: "http://www.amazon.com/dp/081298160X/?tag=devonfir-20", title: "The Power of Habit: Why We Do What We Do in Life and Business", author: "Charles Duhigg"} - { url: "http://www.amazon.com/dp/1592408419/?tag=devonfir-20", title: "Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead", author: "Brené Brown"} tags: - { url: "http://www.amazon.com/dp/193594486X/?tag=devonfir-20", title: "The Slight Edge: Turning Simple Disciplines Into Massive Success", author: "Jeff Olson"} - { url: "http://www.amazon.com/dp/081298160X/?tag=devonfir-20", title: "The Power of Habit: Why We Do What We Do in Life and Business", author: "Charles Duhigg"} - { url: "http://www.amazon.com/dp/1592408419/?tag=devonfir-20", title: "Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead", author: "Brené Brown"} redirect_from: - "/117/" - "/117/" - "/117/" - "/0117/" - "/joyce-akiko-life-on-your-terms/" - "/JoyceAkiko/" - "/Joyce-Akiko/" - "/Podcast/Episodes/117/" - "/Podcast/Episodes/117/" - "/Podcast/Episodes/117/" - "/Podcast/Episodes/0117/" - "/Podcast/Episodes/joyce-akiko-life-on-your-terms/" - "/Podcast/Episodes/JoyceAkiko/" - "/Podcast/Episodes/Joyce-Akiko/" ---
Joyce Akiko is a passionate and dedicated former freelance web developer. Today, her #1 goal is to help people live life on their terms— not someone else’s. Joyce's courses and articles help thousands of people experience freedom and flexibility every day. Her work can be found on dozens of sites, including Lifehacker, Skillcrush, and the Daily Muse. Check out Joyce's training on how to make more money without leaving the security of a full-time job at http://www.freelanceontheside.com. Enrollment is 100% free for Developer on Fire listeners.


These delicious protein-packed fritters are light, making them ideal for breakfast or throughout the day as a snack. Most people use peeled brown beans, ground and blended with onions and spices, and fry in vegetable oil. They taste amazing when eaten with Agege bread. There's a full recipe here
Nigerians love a pottage, and they are most commonly made with yams (Nigeria is one of the top producers of yam in the world). This variation balances the nuttiness of brown beans with the natural sweetness of plantains, and the palm oil adds a rich smoky taste to it.There's a full recipe here
A literal translation from the Yoruba is "mixed greens" and while they are the star of this rich, fragrant vegetable stew, there's so much goodness besides: blended scotch bonnets, bell pepper, onions and locust beans. This is a classic Yoruba dish.There's a full recipe here


Im looking for a PvP monk whos has good ab and a nice stunning fist the server im playing on is low magic rp pvp server stunning fist dc need not be very high(not many ppl going to have high will save), id like to see a monk with highest ab possible any links to builds of this kind or ideas greatly appreciated!
P.S atm server cap is 20 but will be raises in future so it needs to be playable from 5-40 _________________ What I want to find out is -- do parrots know much about Astro-Turf?


--- fulltitle: Bulma Videos layout: default route: videos breadcrumb: - home - videos videos: - id: tesla title: Tesla launch page subtitle: 4 videos – 20 min content: Design a responsive launch page with Bulma's component and CSS Grid. video_url: https://scrimba.com/p/pV5eHk/cvrwyfR article_url: https://medium.freecodecamp.org/how-to-build-a-responsive-tesla-launch-page-with-bulma-css-2bf484057349 - id: blog title: Blog subtitle: 4 videos – 23 min content: Build a responsive blog with Bulma components. video_url: https://scrimba.com/p/pV5eHk/c4EMaUR article_url: https://medium.freecodecamp.org/how-to-build-a-responsive-blog-design-with-bulma-css-c2257a17c16b - id: slide title: Slide subtitle: 4 videos – 15 min content: Create web-based presentation slides with Bulma. video_url: https://scrimba.com/p/pV5eHk/cGym4Ta no_video: true --- {% include global/navbar.html id="Videos" %} {% capture hero_content %} Enroll in the free course {% endcapture %} {% include components/hero.html color="videos" icon="fas fa-play-circle" title="**Video** tutorials" subtitle="Learn Bulma with free interactive Scrimba tutorials" content=hero_content %} {% for video in page.videos %}
{{ video.subtitle }}
{{ video.content }}


Lab 1: Hello HTML - Introduction to HTML & CSS
Lab 2: Using JavaScript to make a Clock
Lab 3a: Lab 3 - Remote Hello World
Lab 3b: Building a Continuous Development Cycle - Commit (January 27)
Lab 4: Weather Clock - Commit (January 29)
Lab 5: Alarm Clock - Commit (February 5)
Lab 6: Twiddle Use Case Diagram - Twiddle Class Diagram
Lab 7: My Clock - Commit (February 19)
I will post my project activities here.
A Portfolio for CPE 409 - Developing With Cloud Services. Winter 2015, Cal Poly.


---
layout: default
title: LCTES 2015
description: Languages, Compilers and Tools for Embedded Systems
current: home
---
About LCTES
LCTES provides a link between the programming languages and embedded systems engineering communities. Researchers and developers in these areas are addressing many similar problems, but with different backgrounds and approaches. LCTES is intended to expose researchers and developers from either area to relevant work and interesting problems in the other area and provide a forum where they can interact.
LCTES 2015 will be part of FCRC 2015 (Federated Computing Research Conference 2015) and will be held in Portland, Oregon, USA. This will be the sixteenth conference in the LCTES series.
Important Dates
| Submission deadline | Feb. 15 |
| Reviews by | Mar. 20 |
| Notifications by | Apr. 1 |
| Camera-ready Deadline | Apr. 11 |
Call for Papers
Embedded system design faces many challenges both with respect to functional requirements and nonfunctional requirements, many of which are conflicting. They are found in areas such as design and developer productivity, verification, validation, maintainability, and meeting performance goals and resource constraints. Novel design-time and run-time approaches are needed to meet the demand of emerging applications and to exploit new hardware paradigms, and in particular to scale up to multicores (including GPUs and FPGAs) and distributed systems built from multicores.
LCTES 2014 solicits papers presenting original work on programming languages, compilers, tools, theory, and architectures that help in overcoming these challenges. Research papers on innovative techniques are welcome, as well as experience papers on insights obtained by experimenting with real-world systems and applications.
Papers are solicited on, but not limited to, the following topics in embedded systems:
- Programming language challenges, including:
- Domain-specific languages
- Features to exploit multicore, reconfigurable, and other emerging architectures
- Features for distributed, adaptive, and real-time control embedded systems
- Language capabilities for specification, composition, and construction of embedded systems
- Language features and techniques to enhance reliability, verifiability, and security
- Virtual machines, concurrency, inter-processor synchronization, and memory management
- Compiler challenges, including:
- Interaction between embedded architectures, operating systems, and compiler
- Interpreters, binary translation, just-in-time compilation, and split compilation
- Support for enhanced programmer productivity
- Support for enhanced debugging, profiling, and exception/interrupt handling
- Optimization for low power/energy, code and data size, and best-effort and real-time performance
- Parameterized and structural compiler design space exploration and autotuning
- Tools for analysis, specification, design, and implementation, including:
- Hardware, system software, application software, and their interfaces
- Distributed real-time control, media players, and reconfigurable architectures
- System integration and testing
- Performance estimation, monitoring, and tuning
- Run-time system support for embedded systems
- Design space exploration tools
- Support for system security and system-level reliability
- Approaches for cross-layer system optimization
- Theory and foundations of embedded systems, including:
- Predictability of resource behavior: energy, space, time
- Validation and verification, in particular of concurrent and distributed systems
- Formal foundations of model-based design as basis for code generation, analysis, and verification
- Mathematical foundations for embedded systems
- Models of computations for embedded applications
- Novel embedded architectures, including:
- Design and implementation of novel architectures
- Workload analysis and performance evaluation
- Architecture support for new language features, virtualization, compiler techniques, debugging tools


--- layout: page title: About header-img: "img/about-bg.png" ---
I have varied professional experiences: main frame programmer, Math teacher, and now becoming a software developer


{include file="public/head" /}
工学部综合系统-第二课堂
{include file="public/nav_nologin" /}
讲师列表
List of lecturers
讲师
Lecturers
{include file="public/foot" /}


{% extends "layout.html" %}
{% block title %}
Take Action Today
{% endblock %}
{% block main %}
Activism isn't always the most accessible or intuitive. We're here to change that.
A protest can take many forms, from assembling in solidarity for a cause, or with those who share a marginalized identity, to marching to your local statehouse and making demands. Use our tools to ensure that you're informed and effective.
Always wanted to attend a protest, but don't know where to start? Click here!
Want to know the steps to keep you and your loved ones safe while attending protests? We've got you, right here.
Just want to know what's happening across the country? Look no further than here.


| 1007569 |
Park 1
4425 Garrett Park Rd
|
Garbage
|
There is Garbage spill all over the kids play area. Please look into it.
|
| 1007570 |
Park 2
3rd St & Armstrong Ave.
|
Oil Spill
|
There is Oil spill under the benches. Please look into it.
|
| 1007571 |
Park 2
3rd St & Armstrong Ave.
|
Nuclear Waste
|
Park has a lot of Nuclear Waste. Please look into it.
|
| 1007572 |
Park 2
3rd St & Armstrong Ave.
|
Nuclear Waste
|
Park has a lot of Nuclear Waste. Please look into it.
|
| 1007573 |
Park 2
3rd St & Armstrong Ave.
|
Nuclear Waste
|
Park has a lot of Nuclear Waste. Please look into it.
|


Pau Gasol seeking treatment in Spain
Free agent Pau Gasol is in Murcia considering further options on the recovery from his left foot injury.
By John Askounis/<EMAIL_ADDRESS>A few days after being waived by the Portland Trail Blazers, Pau Gasol returned to Spain. He made his way to Murcia to gather further options on his recovery, per Marca. He went through left foot surgery last May, but his rehabilitation did not go as planned.
After visiting many foot specialists in USA, he decided to seek diagnoses from his homeland as well. The 39-year-old Spaniard big hopes to get back on the courts as soon as possible with his main goal being the 2020 Olympic Games with the Spanish national team. However hasn’t played since March due to his injury.


IECSE presents
March 30th-40th
Some Guy: +91<PHONE_NUMBER>
Sidekick Boi: +91<PHONE_NUMBER>
Made with fingers (🖕) by IECSE


about
I currently live in NYC and study at NYU Law School. I also do work on large-scale data collection and analytics, and a little bit of angel investing.
I worked on data security, privacy, and “smart” street grids at Sidewalk Labs.
I was director of product engineering at Braze in 2016 and 2017.
I was a software engineer at Dropbox from 2011 - 2015. I focused mostly on making large-scale data analytics accessible to non-engineers. I also spent time on security incident response, prototyping, internal tools, and sales and support automation.
From 2009-2011 I did research in distributed robotics at MIT CSAIL, where I designed and built heterogeneous robot swarms to prove feasibility of automated distributed construction of large structures.
Resume - Publications - Thesis