WITNESS LIST
Appropriations - S/C on Articles VI, VII & VIII Committee
February 20, 2017 - 7:30 AM
Texas Department of Housing and Community Affairs
On:
Borders, Darrion (Self; LifeWorks)
Cervantes, David (Texas Department of Housing and Community Affairs)
Cormier, Emily (Legislative Budget Board)
Gendron, Christine (Self; Texas network of youth services)
Irvine, Tim (Texas Department of Housing and Community Affairs)
Kemp, Gage (Lifeworks Youth Advisory Council)
Krog, Elizabeth (Legislative Budget Board)
Samuels, Eric (Texas Homeless Network)
Wilkinson, Bill (Roy Maas Youth Alternatives and the Texas Network of Youth Services)
Williams, Olivia (Self)
Registering, but not testifying:
On:
Garcia, Joe (Texas Department of Housing and Community Affairs - Manufactured Housing)
Howe, Curtis (Texas Department of Housing and Community Affairs)
Texas Department of Motor Vehicles
On:
Brewster, Whitney (Texas Department of Motor Vehicles)
Galvan, Thomas (Legislative Budget Board)
Garcia, Carlos (Auto Burglary and Theft Prevention Authority Chairman)
Hansen, Tommy (Auto Burglary and Theft Prevention Authority)
Registering, but not testifying:
On:
Cormier, Emily (Legislative Budget Board)
Flores, Linda (Texa Department of Motor Vehicles)
Harbeson, Bill (Texas Department of Motor Vehicles)
Kuntz, Jeremiah (Texas Department of Motor Vehicles)
Mellott, Shelly (Texas Department of Motor Vehicles)
Obermier, Eric (Texas Department of Motor Vehicles)
Wilson, Bryan (ABTPA/TXDMV)
Texas Department of Transportation
On:
Bolding, Lann (Legislative budget board)
Elliott, Verma (State Auditor's Office)
Galvan, Thomas (Legislative Budget Board)
Griffin, Justin (State Auditor's Office)
Ragland, Brian (TxDOT)
Tripp, Amy (Sunset Advisory Commission)
Williams, Marc (TxDOT)
1
WITNESS LIST
Registering, but not testifying:
On:
Anderson, Darran (TxDOT)
Cormier, Emily (Legislative Budget Board)
Gleason, Eric (TxDOT)
Hale, Bill (TxDOT)
Harmon, Dan (TxDOT)
McMonagle, Rich (TxDOT)
Sexton, Linda (TxDOT)
Wilson, Gil (TxDOT)
Texas Lottery Commission
On:
Cormier, Emily (Legislative Budget Board)
Grief, Gary (Texas Lottery Commission)
Overmyer, Andrew (Legislative Budget Board)
Pugh, Jacob (Legislative Budget Board)
Royal III, Alfonso (Texas Lottery)
Registering, but not testifying:
On:
Pyka, Kathy (Texas Lottery)
Texas Workforce Commission
On:
Alcantar, Andres (Texas Workforce Commission)
Perdue, Caitlin (Legislative Budget Board)
Temple, Larry (Texas Workforce Commission)
Townsend, Randy (Texas Workforce Commission)
Registering, but not testifying:
On:
Cormier, Emily (Legislative Budget Board)
2


Simulcast is a multimedia art project driven by Los Angeles tenant Tristan Friedberg Rodman.
Focused by grief, climate change, and critical histories of their city, Simulcast's work cuts from net art, creative nonfiction, and indie rock.
It sprawls, fractured and interconnected, like Los Angeles itself.


The root of the directory tree for read-only architecture-independent data files. This should normally be /usr/local/share, but write it as $(prefix)/share. (If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>‘datadir’’s default value is based on this variable; so are ‘infodir’, ‘mandir’, and others.
The directory for installing idiosyncratic read-only architecture-independent data files for this program. This is usually the same place as ‘datarootdir’, but we use the two separate variables so that you can move these program-specific files without altering the location for Info files, man pages, etc.
This should normally be /usr/local/share, but write it as $(datarootdir). (If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>The definition of ‘datadir’ is the same for all packages, so you should install your data in a subdirectory thereof. Most packages install their data under $(datadir)/package-name/.
The directory for installing read-only data files that pertain to a single machine–that is to say, files for configuring a host. Mailer and network configuration files, /etc/passwd, and so forth belong here. All the files in this directory should be ordinary ASCII text files. This directory should normally be /usr/local/etc, but write it as $(prefix)/etc. (If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>Do not install executables here in this directory (they probably belong in $(libexecdir) or $(sbindir)). Also do not install files that are modified in the normal course of their use (programs whose purpose is to change the configuration of the system excluded). Those probably belong in $(localstatedir).
The directory for installing architecture-independent data files which the programs modify while they run. This should normally be /usr/local/com, but write it as $(prefix)/com. (If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>The directory for installing data files which the programs modify while they run, and that pertain to one specific machine. Users should never need to modify files in this directory to configure the package’s operation; put such configuration information in separate files that go in $(datadir) or $(sysconfdir). $(localstatedir) should normally be /usr/local/var, but write it as $(prefix)/var. (If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>The directory for installing data files which the programs modify
while they run, that pertain to one specific machine, and which need
not persist longer than the execution of the program—which is
generally long-lived, for example, until the next reboot. PID files
for system daemons are a typical use. In addition, this directory
should not be cleaned except perhaps at reboot, while the general
/tmp (TMPDIR
) may be cleaned arbitrarily. This should
normally be /var/run, but write it as
$(localstatedir)/run. Having it as a separate variable allows
the use of /run if desired, for example. (If you are using
Autoconf 2.70 or later, write it as ‘<EMAIL_ADDRESS>These variables specify the directory for installing certain specific types of files, if your program has them. Every GNU package should have Info files, so every program needs ‘infodir’, but not all need ‘libdir’ or ‘lispdir’.
The directory for installing header files to be included by user programs with the C ‘#include’ preprocessor directive. This should normally be /usr/local/include, but write it as $(prefix)/include. (If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>Most compilers other than GCC do not look for header files in directory
/usr/local/include. So installing the header files this way is
only useful with GCC. Sometimes this is not a problem because some
libraries are only really intended to work with GCC. But some libraries
are intended to work with other compilers. They should install their
header files in two places, one specified by includedir
and one
specified by oldincludedir
.
The directory for installing ‘#include’ header files for use with compilers other than GCC. This should normally be /usr/include. (If you are using Autoconf, you can write it as ‘<EMAIL_ADDRESS>The Makefile commands should check whether the value of
oldincludedir
is empty. If it is, they should not try to use
it; they should cancel the second installation of the header files.
A package should not replace an existing header in this directory unless
the header came from the same package. Thus, if your Foo package
provides a header file foo.h, then it should install the header
file in the oldincludedir
directory if either (1) there is no
foo.h there or (2) the foo.h that exists came from the Foo
package.
To tell whether foo.h came from the Foo package, put a magic
string in the file—part of a comment—and grep
for that string.
The directory for installing documentation files (other than Info) for this package. By default, it should be /usr/local/share/doc/yourpkg, but it should be written as $(datarootdir)/doc/yourpkg. (If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>The yourpkg subdirectory, which may include a version number, prevents collisions among files with common names, such as README.
The directory for installing the Info files for this package. By
default, it should be /usr/local/share/info, but it should be
written as $(datarootdir)/info. (If you are using Autoconf,
write it as ‘<EMAIL_ADDRESS>infodir
is separate from
docdir
for compatibility with existing practice.
Directories for installing documentation files in the particular
format. They should all be set to $(docdir)
by default. (If
you are using Autoconf, write them as ‘@htmldir@’,
‘@dvidir@’, etc.) Packages which supply several translations
of their documentation should install them in
‘$(htmldir)/’ll, ‘$(pdfdir)/’ll, etc. where
ll is a locale abbreviation such as ‘en’ or ‘pt_BR’.
The directory for object files and libraries of object code. Do not
install executables here, they probably ought to go in $(libexecdir)
instead. The value of libdir
should normally be
/usr/local/lib, but write it as $(exec_prefix)/lib.
(If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>The directory for installing any Emacs Lisp files in this package. By default, it should be /usr/local/share/emacs/site-lisp, but it should be written as $(datarootdir)/emacs/site-lisp.
If you are using Autoconf, write the default as ‘@lispdir@’. In order to make ‘@lispdir@’ work, you need the following lines in your configure.ac file:
lispdir='${datarootdir}/emacs/site-lisp' AC_SUBST(lispdir)
The directory for installing locale-specific message catalogs for this package. By default, it should be /usr/local/share/locale, but it should be written as $(datarootdir)/locale. (If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>This directory usually has a subdirectory per locale.
Unix-style man pages are installed in one of the following:
The top-level directory for installing the man pages (if any) for this package. It will normally be /usr/local/share/man, but you should write it as $(datarootdir)/man. (If you are using Autoconf, write it as ‘<EMAIL_ADDRESS>The directory for installing section 1 man pages. Write it as $(mandir)/man1.
The directory for installing section 2 man pages. Write it as $(mandir)/man2
Don’t make the primary documentation for any GNU software be a man page. Write a manual in Texinfo instead. Man pages are just for the sake of people running GNU software on Unix, which is a secondary application only.
The file name extension for the installed man page. This should contain a period followed by the appropriate digit; it should normally be ‘.1’.
The file name extension for installed section 1 man pages.
The file name extension for installed section 2 man pages.
Use these names instead of ‘manext’ if the package needs to install man pages in more than one section of the manual.
And finally, you should set the following variable:
The directory for the sources being compiled. The value of this
variable is normally inserted by the configure
shell script.
(If you are using Autoconf, use ‘srcdir =<EMAIL_ADDRESS>For example:
# Common prefix for installation directories. # NOTE: This directory must exist when you start the install. prefix = /usr/local datarootdir = $(prefix)/share datadir = $(datarootdir) exec_prefix = $(prefix) # Where to put the executable for the command 'gcc'. bindir = $(exec_prefix)/bin # Where to put the directories used by the compiler. libexecdir = $(exec_prefix)/libexec # Where to put the Info files. infodir = $(datarootdir)/info
If your program installs a large number of files into one of the
standard user-specified directories, it might be useful to group them
into a subdirectory particular to that program. If you do this, you
should write the install
rule to create these subdirectories.
Do not expect the user to include the subdirectory name in the value of any of the variables listed above. The idea of having a uniform set of variable names for installation directories is to enable the user to specify the exact same values for several different GNU packages. In order for this to be useful, all the packages must be designed so that they will work sensibly when the user does so.
At times, not all of these variables may be implemented in the current release of Autoconf and/or Automake; but as of Autoconf 2.60, we believe all of them are. When any are missing, the descriptions here serve as specifications for what Autoconf will implement. As a programmer, you can either use a development version of Autoconf or avoid using these variables until a stable release is made which supports them.
Next: Install Command Categories, Previous: Directory Variables, Up: Makefile Conventions [Contents][Index]
All GNU programs should have the following targets in their Makefiles:
Compile the entire program. This should be the default target. This target need not rebuild any documentation files; Info files should normally be included in the distribution, and DVI (and other documentation format) files should be made only when explicitly asked for.
By default, the Make rules should compile and link with ‘-g’, so that executable programs have debugging symbols. Otherwise, you are essentially helpless in the face of a crash, and it is often far from easy to reproduce with a fresh build.
Compile the program and copy the executables, libraries, and so on to the file names where they should reside for actual use. If there is a simple test to verify that a program is properly installed, this target should run that test.
Do not strip executables when installing them. This helps eventual
debugging that may be needed later, and nowadays disk space is cheap
and dynamic loaders typically ensure debug sections are not loaded during
normal execution. Users that need stripped binaries may invoke the
install-strip
target to do that.
If possible, write the install
target rule so that it does not
modify anything in the directory where the program was built, provided
‘make all’ has just been done. This is convenient for building the
program under one user name and installing it under another.
The commands should create all the directories in which files are to be
installed, if they don’t already exist. This includes the directories
specified as the values of the variables prefix
and
exec_prefix
, as well as all subdirectories that are needed.
One way to do this is by means of an installdirs
target
as described below.
Use ‘-’ before any command for installing a man page, so that
make
will ignore any errors. This is in case there are systems
that don’t have the Unix man page documentation system installed.
The way to install Info files is to copy them into $(infodir)
with $(INSTALL_DATA)
(see Command Variables), and then run
the install-info
program if it is present. install-info
is a program that edits the Info dir file to add or update the
menu entry for the given Info file; it is part of the Texinfo package.
Here is a sample rule to install an Info file that also tries to
handle some additional situations, such as install-info
not
being present.
do-install-info: foo.info installdirs $(NORMAL_INSTALL) # Prefer an info file in . to one in srcdir. if test -f foo.info; then d=.; \ else d="$(srcdir)"; fi; \ $(INSTALL_DATA) $$d/foo.info \ "$(DESTDIR)$(infodir)/foo.info" # Run install-info only if it exists. # Use 'if' instead of just prepending '-' to the # line so we notice real errors from install-info. # Use '$(SHELL) -c' because some shells do not # fail gracefully when there is an unknown command. $(POST_INSTALL) if $(SHELL) -c 'install-info --version' \ >/dev/null 2>&1; then \ install-info --dir-file="$(DESTDIR)$(infodir)/dir" \ "$(DESTDIR)$(infodir)/foo.info"; \ else true; fi
When writing the install
target, you must classify all the
commands into three categories: normal ones, pre-installation
commands and post-installation commands. See Install Command Categories.
These targets install documentation in formats other than Info;
they’re intended to be called explicitly by the person installing the
package, if that format is desired. GNU prefers Info files, so these
must be installed by the install
target.
When you have many documentation files to install, we recommend that
you avoid collisions and clutter by arranging for these targets to
install in subdirectories of the appropriate installation directory,
such as htmldir
. As one example, if your package has multiple
manuals, and you wish to install HTML documentation with many files
(such as the “split” mode output by makeinfo --html
), you’ll
certainly want to use subdirectories, or two nodes with the same name
in different manuals will overwrite each other.
Please make these install-format
targets invoke the
commands for the format target, for example, by making
format a dependency.
Delete all the installed files—the copies that the ‘install’ and ‘install-*’ targets create.
This rule should not modify the directories where compilation is done, only the directories where files are installed.
The uninstallation commands are divided into three categories, just like the installation commands. See Install Command Categories.
Like install
, but strip the executable files while installing
them. In simple cases, this target can use the install
target in
a simple way:
install-strip: $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \ install
But if the package installs scripts as well as real executables, the
install-strip
target can’t just refer to the install
target; it has to strip the executables but not the scripts.
install-strip
should not strip the executables in the build
directory which are being copied for installation. It should only strip
the copies that are installed.
Normally we do not recommend stripping an executable unless you are sure the program has no bugs. However, it can be reasonable to install a stripped executable for actual execution while saving the unstripped executable elsewhere in case there is a bug.
Delete all files in the current directory that are normally created by building the program. Also delete files in other directories if they are created by this makefile. However, don’t delete the files that record the configuration. Also preserve files that could be made by building, but normally aren’t because the distribution comes with them. There is no need to delete parent directories that were created with ‘mkdir -p’, since they could have existed anyway.
Delete .dvi files here if they are not part of the distribution.
Delete all files in the current directory (or created by this makefile) that are created by configuring or building the program. If you have unpacked the source and built the program without creating any other files, ‘make distclean’ should leave only the files that were in the distribution. However, there is no need to delete parent directories that were created with ‘mkdir -p’, since they could have existed anyway.
Like ‘clean’, but may refrain from deleting a few files that people normally don’t want to recompile. For example, the ‘mostlyclean’ target for GCC does not delete libgcc.a, because recompiling it is rarely necessary and takes a lot of time.
Delete almost everything that can be reconstructed with this Makefile.
This typically includes everything deleted by distclean
, plus
more: C source files produced by Bison, tags tables, Info files, and
so on.
The reason we say “almost everything” is that running the command
‘make maintainer-clean’ should not delete configure even
if configure can be remade using a rule in the Makefile. More
generally, ‘make maintainer-clean’ should not delete anything
that needs to exist in order to run configure and then begin to
build the program. Also, there is no need to delete parent
directories that were created with ‘mkdir -p’, since they could
have existed anyway. These are the only exceptions;
maintainer-clean
should delete everything else that can be
rebuilt.
The ‘maintainer-clean’ target is intended to be used by a maintainer of the package, not by ordinary users. You may need special tools to reconstruct some of the files that ‘make maintainer-clean’ deletes. Since these files are normally included in the distribution, we don’t take care to make them easy to reconstruct. If you find you need to unpack the full distribution again, don’t blame us.
To help make users aware of this, the commands for the special
maintainer-clean
target should start with these two:
@echo 'This command is intended for maintainers to use; it' @echo 'deletes files that may need special tools to rebuild.'
Update a tags table for this program.
Generate any Info files needed. The best way to write the rules is as follows:
info: foo.info foo.info: foo.texi chap1.texi chap2.texi $(MAKEINFO) $(srcdir)/foo.texi
You must define the variable MAKEINFO
in the Makefile. It should
run the makeinfo
program, which is part of the Texinfo
distribution.
Normally a GNU distribution comes with Info files, and that means the Info files are present in the source directory. Therefore, the Make rule for an info file should update it in the source directory. When users build the package, ordinarily Make will not update the Info files because they will already be up to date.
Generate documentation files in the given format. These targets
should always exist, but any or all can be a no-op if the given output
format cannot be generated. These targets should not be dependencies
of the all
target; the user must manually invoke them.
Here’s an example rule for generating DVI files from Texinfo:
dvi: foo.dvi foo.dvi: foo.texi chap1.texi chap2.texi $(TEXI2DVI) $(srcdir)/foo.texi
You must define the variable TEXI2DVI
in the Makefile. It
should run the program texi2dvi
, which is part of the Texinfo
distribution. (texi2dvi
uses TeX to do the real work of
formatting. TeX is not distributed with Texinfo.) Alternatively,
write only the dependencies, and allow GNU make
to provide the
command.
Here’s another example, this one for generating HTML from Texinfo:
html: foo.html foo.html: foo.texi chap1.texi chap2.texi $(TEXI2HTML) $(srcdir)/foo.texi
Again, you would define the variable TEXI2HTML
in the Makefile;
for example, it might run makeinfo --no-split --html
(makeinfo
is part of the Texinfo distribution).
Create a distribution tar file for this program. The tar file should be set up so that the file names in the tar file start with a subdirectory name which is the name of the package it is a distribution for. This name can include the version number.
For example, the distribution tar file of GCC version 1.40 unpacks into a subdirectory named gcc-1.40.
The easiest way to do this is to create a subdirectory appropriately
named, use ln
or cp
to install the proper files in it, and
then tar
that subdirectory.
Compress the tar file with gzip
. For example, the actual
distribution file for GCC version 1.40 is called gcc-1.40.tar.gz.
It is ok to support other free compression formats as well.
The dist
target should explicitly depend on all non-source files
that are in the distribution, to make sure they are up to date in the
distribution.
See Making Releases.
Perform self-tests (if any). The user must build the program before running the tests, but need not install the program; you should write the self-tests so that they work when the program is built but not installed.
The following targets are suggested as conventional names, for programs in which they are useful.
installcheck
Perform installation tests (if any). The user must build and install the program before running the tests. You should not assume that $(bindir) is in the search path.
installdirs
It’s useful to add a target named ‘installdirs’ to create the directories where files are installed, and their parent directories. There is a script called mkinstalldirs which is convenient for this; you can find it in the Gnulib package. You can use a rule like this:
# Make sure all installation directories (e.g. $(bindir)) # actually exist by making them if necessary. installdirs: mkinstalldirs $(srcdir)/mkinstalldirs $(bindir) $(datadir) \ $(libdir) $(infodir) \ $(mandir)
or, if you wish to support DESTDIR
(strongly encouraged),
# Make sure all installation directories (e.g. $(bindir)) # actually exist by making them if necessary. installdirs: mkinstalldirs $(srcdir)/mkinstalldirs \ $(DESTDIR)$(bindir) $(DESTDIR)$(datadir) \ $(DESTDIR)$(libdir) $(DESTDIR)$(infodir) \ $(DESTDIR)$(mandir)
This rule should not modify the directories where compilation is done. It should do nothing but create installation directories.
Previous: Standard Targets, Up: Makefile Conventions [Contents][Index]
When writing the install
target, you must classify all the
commands into three categories: normal ones, pre-installation
commands and post-installation commands.
Normal commands move files into their proper places, and set their modes. They may not alter any files except the ones that come entirely from the package they belong to.
Pre-installation and post-installation commands may alter other files; in particular, they can edit global configuration files or data bases.
Pre-installation commands are typically executed before the normal commands, and post-installation commands are typically run after the normal commands.
The most common use for a post-installation command is to run
install-info
. This cannot be done with a normal command, since
it alters a file (the Info directory) which does not come entirely and
solely from the package being installed. It is a post-installation
command because it needs to be done after the normal command which
installs the package’s Info files.
Most programs don’t need any pre-installation commands, but we have the feature just in case it is needed.
To classify the commands in the install
rule into these three
categories, insert category lines among them. A category line
specifies the category for the commands that follow.
A category line consists of a tab and a reference to a special Make variable, plus an optional comment at the end. There are three variables you can use, one for each category; the variable name specifies the category. Category lines are no-ops in ordinary execution because these three Make variables are normally undefined (and you should not define them in the makefile).
Here are the three possible category lines, each with a comment that explains what it means:
$(PRE_INSTALL) # Pre-install commands follow. $(POST_INSTALL) # Post-install commands follow. $(NORMAL_INSTALL) # Normal commands follow.
If you don’t use a category line at the beginning of the install
rule, all the commands are classified as normal until the first category
line. If you don’t use any category lines, all the commands are
classified as normal.
These are the category lines for uninstall
:
$(PRE_UNINSTALL) # Pre-uninstall commands follow. $(POST_UNINSTALL) # Post-uninstall commands follow. $(NORMAL_UNINSTALL) # Normal commands follow.
Typically, a pre-uninstall command would be used for deleting entries from the Info directory.
If the install
or uninstall
target has any dependencies
which act as subroutines of installation, then you should start
each dependency’s commands with a category line, and start the
main target’s commands with a category line also. This way, you can
ensure that each command is placed in the right category regardless of
which of the dependencies actually run.
Pre-installation and post-installation commands should not run any programs except for these:
[ basename bash cat chgrp chmod chown cmp cp dd diff echo egrep expand expr false fgrep find getopt grep gunzip gzip hostname install install-info kill ldconfig ln ls md5sum mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee test touch true uname xargs yes
The reason for distinguishing the commands in this way is for the sake of making binary packages. Typically a binary package contains all the executables and other files that need to be installed, and has its own method of installing them—so it does not need to run the normal installation commands. But installing the binary package does need to execute the pre-installation and post-installation commands.
Programs to build binary packages work by extracting the
pre-installation and post-installation commands. Here is one way of
extracting the pre-installation commands (the -s option to
make
is needed to silence messages about entering
subdirectories):
make -s -n install -o all \ PRE_INSTALL=pre-install \ POST_INSTALL=post-install \ NORMAL_INSTALL=normal-install \ | gawk -f pre-install.awk
where the file pre-install.awk could contain this:
$0 ~ /^(normal-install|post-install)[ \t]*$/ {on = 0} on {print $0} $0 ~ /^pre-install[ \t]*$/ {on = 1}
Previous: Makefile Conventions, Up: Managing Releases [Contents][Index]
You should identify each release with a pair of version numbers, a major version and a minor. We have no objection to using more than two numbers, but it is very unlikely that you really need them.
Package the distribution of Foo version 69.96
up in a gzipped tar
file with the name foo-69.96.tar.gz. It should unpack into a
subdirectory named foo-69.96.
Building and installing the program should never modify any of the files contained in the distribution. This means that all the files that form part of the program in any way must be classified into source files and non-source files. Source files are written by humans and never changed automatically; non-source files are produced from source files by programs under the control of the Makefile.
The distribution should contain a file named README with a general overview of the package:
Naturally, all the source files must be in the distribution. It is
okay to include non-source files in the distribution along with the
source files they are generated from, provided they are up-to-date
with the source they are made from, and machine-independent, so that
normal building of the distribution will never modify them. We
commonly include non-source files produced by Autoconf, Automake,
Bison, flex
, TeX, and makeinfo
; this helps avoid
unnecessary dependencies between our distributions, so that users can
install whichever versions of whichever packages they like. Do not
induce new dependencies on other software lightly.
Non-source files that might actually be modified by building and installing the program should never be included in the distribution. So if you do distribute non-source files, always make sure they are up to date when you make a new distribution.
Make sure that all the files in the distribution are world-readable, and
that directories are world-readable and world-searchable (octal mode 755).
We used to recommend that all directories in the distribution also be
world-writable (octal mode 777), because ancient versions of tar
would otherwise not cope when extracting the archive as an unprivileged
user. That can easily lead to security issues when creating the archive,
however, so now we recommend against that.
Don’t include any symbolic links in the distribution itself. If the tar file contains symbolic links, then people cannot even unpack it on systems that don’t support symbolic links. Also, don’t use multiple names for one file in different directories, because certain file systems cannot handle this and that prevents unpacking the distribution.
Try to make sure that all the file names will be unique on MS-DOS. A name on MS-DOS consists of up to 8 characters, optionally followed by a period and up to three characters. MS-DOS will truncate extra characters both before and after the period. Thus, foobarhacker.c and foobarhacker.o are not ambiguous; they are truncated to foobarha.c and foobarha.o, which are distinct.
Include in your distribution a copy of the texinfo.tex you used to test print any *.texinfo or *.texi files.
Likewise, if your program uses small GNU software packages like regex, getopt, obstack, or termcap, include them in the distribution file. Leaving them out would make the distribution file a little smaller at the expense of possible inconvenience to a user who doesn’t know what other files to get.
Next: GNU Free Documentation License, Previous: Managing Releases, Up: Top [Contents][Index]
A GNU program should not recommend, promote, or grant legitimacy to the use of any non-free program. Proprietary software is a social and ethical problem, and our aim is to put an end to that problem. We can’t stop some people from writing proprietary programs, or stop other people from using them, but we can and should refuse to advertise them to new potential customers, or to give the public the idea that their existence is ethical.
The GNU definition of free software is found on the GNU web site at http://www.gnu.org/philosophy/free-sw.html, and the definition of free documentation is found at http://www.gnu.org/philosophy/free-doc.html. The terms “free” and “non-free”, used in this document, refer to those definitions.
A list of important licenses and whether they qualify as free is in http://www.gnu.org/licenses/license-list.html. If it is not clear whether a license qualifies as free, please ask the GNU Project by writing to<EMAIL_ADDRESS>We will answer, and if the license is an important one, we will add it to the list.
When a non-free program or system is well known, you can mention it in passing—that is harmless, since users who might want to use it probably already know about it. For instance, it is fine to explain how to build your package on top of some widely used non-free operating system, or how to use it together with some widely used non-free program.
However, you should give only the necessary information to help those who already use the non-free program to use your program with it—don’t give, or refer to, any further information about the proprietary program, and don’t imply that the proprietary program enhances your program, or that its existence is in any way a good thing. The goal should be that people already using the proprietary program will get the advice they need about how to use your free program with it, while people who don’t already use the proprietary program will not see anything likely to lead them to take an interest in it.
If a non-free program or system is obscure in your program’s domain, your program should not mention or support it at all, since doing so would tend to popularize the non-free program more than it popularizes your program. (You cannot hope to find many additional users for your program among the users of Foobar, if the existence of Foobar is not generally known among people who might want to use your program.)
Sometimes a program is free software in itself but depends on a non-free platform in order to run. For instance, many Java programs depend on some non-free Java libraries. To recommend or promote such a program is to promote the other programs it needs. This is why we are careful about listing Java programs in the Free Software Directory: we don’t want to promote the non-free Java libraries.
We hope this particular problem with Java will be gone by and by, as we replace the remaining non-free standard Java libraries with free software, but the general principle will remain the same: don’t recommend, promote or legitimize programs that depend on non-free software to run.
Some free programs strongly encourage the use of non-free software. A
typical example is mplayer
. It is free software in itself,
and the free code can handle some kinds of files. However,
mplayer
recommends use of non-free codecs for other kinds of
files, and users that install mplayer
are very likely to
install those codecs along with it. To recommend mplayer
is, in effect, to promote use of the non-free codecs.
Thus, you should not recommend programs that strongly encourage the
use of non-free software. This is why we do not list
mplayer
in the Free Software Directory.
A GNU package should not refer the user to any non-free documentation for free software. Free documentation that can be included in free operating systems is essential for completing the GNU system, or any free operating system, so encouraging it is a priority; to recommend use of documentation that we are not allowed to include undermines the impetus for the community to produce documentation that we can include. So GNU packages should never recommend non-free documentation.
By contrast, it is ok to refer to journal articles and textbooks in the comments of a program for explanation of how it functions, even though they are non-free. This is because we don’t include such things in the GNU system even if they are free—they are outside the scope of what a software distribution needs to include.
Referring to a web site that describes or recommends a non-free program is promoting that program, so please do not make links to (or mention by name) web sites that contain such material. This policy is relevant particularly for the web pages for a GNU package.
Following links from nearly any web site can lead eventually to non-free software; this is inherent in the nature of the web. So it makes no sense to criticize a site for having such links. As long as the site does not itself recommend a non-free program, there is no need to consider the question of the sites that it links to for other reasons.
Thus, for example, you should not refer to AT&T’s web site if that recommends AT&T’s non-free software packages; you should not refer to a page p that links to AT&T’s site presenting it as a place to get some non-free program, because that part of the page p itself recommends and legitimizes the non-free program. However, that p contains a link to AT&T’s web site for some other purpose (such as long-distance telephone service) is not an objection against it.
A web page recommends a program in a particularly strong way if it requires users to run that program in order to use the page. Many pages contain Javascript code which they recommend in this way. This Javascript code may be free or nonfree, but nonfree is the usual case.
If the purpose for which you would refer to the page cannot be carried out without running nonfree Javascript code, then you should not refer to it. Thus, if the purpose of referring to the page is for people to view a video, or subscribing to a mailing list, and the viewing or subscribing fail to work if the user’s browser blocks the nonfree Javascript code, then don’t refer to that page.
The extreme case is that of web sites which depend on nonfree
Javascript code even to see the contents of the pages. Any
site hosted on ‘wix.com
’ has this problem, and so do some
other sites. Referring people to such pages to read their contents
is, in effect, urging them to run those nonfree programs—so please
don’t refer to those pages. (Such pages also break the Web, so they
deserve condemnation for two reasons.)
Instead, please quote excerpts from the page to make your point, or find another place to refer to that information.
Next: Index, Previous: References, Up: Top [Contents][Index]
Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. http://fsf.org/ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.
The “publisher” means any person or entity that distributes copies of the Document to the public.
A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.
You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements.”
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Document.
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A “Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMC site.
“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization.
“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.
An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (C) year your name. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with…Texts.” line with this:
with the Invariant Sections being list their titles, with the Front-Cover Texts being list, and with the Back-Cover Texts being list.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
Previous: GNU Free Documentation License, Up: Top [Contents][Index]
| Jump to: | #
-
A B C D E F G I K L M N O P Q R S T U V W X |
|---|
| Jump to: | #
-
A B C D E F G I K L M N O P Q R S T U V W X |
|---|


Car Photos
This photo was taken in a Redwood City dog park. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___
This photo was taken in a Redwood City dog park. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___
This photo was taken in a Redwood City dog park. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___
This photo was taken in a Redwood City dog park. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___
This photo was taken in a Redwood City dog park. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___
pets
This photo was taken at the San Jose Observatory suring a metor shower. I used a 1.8 fixed 35mm lense on a Nikon D3300. This photo was taken with and f stop of 1.8, a shutter speed of ___, and an iso of ___
This photo was taken at the San Jose Observatory suring a metor shower. I used a 1.8 fixed 35mm lense on a Nikon D3300. This photo was taken with and f stop of 1.8, a shutter speed of ___, and an iso of ___
This photo was taken at the San Jose Observatory suring a metor shower. I used a 1.8 fixed 35mm lense on a Nikon D3300. This photo was taken with and f stop of 1.8, a shutter speed of ___, and an iso of ___
This photo was taken at the San Jose Observatory suring a metor shower. I used a 1.8 fixed 35mm lense on a Nikon D3300. This photo was taken with and f stop of 1.8, a shutter speed of ___, and an iso of ___
This photo was taken at the San Jose Observatory suring a metor shower. I used a 1.8 fixed 35mm lense on a Nikon D3300. This photo was taken with and f stop of 1.8, a shutter speed of ___, and an iso of ___
This photo was taken at the San Jose Observatory suring a metor shower. I used a 1.8 fixed 35mm lense on a Nikon D3300. This photo was taken with and f stop of 1.8, a shutter speed of ___, and an iso of ___
long exposure
This photo was taken at the San Jose Observatory suring a metor shower. I used a 1.8 fixed 35mm lense on a Nikon D3300. This photo was taken with and f stop of 1.8, a shutter speed of ___, and an iso of ___
This photo was taken at the San Jose Observatory suring a metor shower. I used a 1.8 fixed 35mm lense on a Nikon D3300. This photo was taken with and f stop of 1.8, a shutter speed of ___, and an iso of ___
black and white
The photo is taken of Erik Rodriguez while doing homework. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___
The photo is taken of Erik Rodriguez while doing homework. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___
The photo is taken of Erik Rodriguez while doing homework. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___
The photo is taken of Erik Rodriguez while doing homework. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___
The photo is taken of Erik Rodriguez while doing homework. I used a 3.4 zoom 80-200mm lense on a Nikon D3300. This photo was taken with and f stop of 3.4, a shutter speed of ___, and an iso of ___


|
gadget - A container gadget handle
index - Integer index of the item to select |
|
Sets the specified item to be the 'current' item.
The exact behaviour depends on the actual kind of gadget, but this typically involves the gadget moving the specified item into view. This command may only be used with combobox, listbox and tabber gadgets. |


November 23, 2019
This is My First Article
Bacon ipsum dolor amet pastrami
shank bacon ribeye cow, shoulder sausage corned beef. Venison biltong jerky jowl frankfurter chicken venison shoulder pork loin capicola shank tenderloin andouille ham turducken fatback turkey drumstick.
frankfurter rump, ground round drumstick. Kevin
landjaeger beef ribs ribeye corned beef.
Bacon brisket leberkas, filet mignon beef ribs
turkey ham tail salami frankfurter landjaeger shank
strip steak. Beef chislic ground round capicola
landjaeger spare ribs shankle flank pork loin
hamburger. Shoulder beef ribs prosciutto doner
boudin buffalo meatball rump kielbasa chislic ham
hock salami alcatra pig. Pork chop tri-tip shankle,
burgdoggen ground round tail kevin.
Filet mignon bacon jowl prosciutto, andouille bresaola meatloaf. Ham hock short loin bresaola corned beef, tongue ball tip turducken beef ribs jowl shank t-bone.  Landjaeger pork chop pork loin pork rump. Filet mignon pastrami fatback, swine shank chuck porchetta venison.  Tri-tip pastrami turkey sirloin bresaola pork belly.
December 19, 2019
This is Another Article
Hamburger alcatra bacon short ribs, ham hock chicken beef chislic picanha kielbasa drumstick swine pork loin meatball. Jowl short ribs chislic, ball tip tenderloin rump andouille shankle venison turducken burgdoggen tongue sirloin. Venison ham boudin tail jowl, sausage chislic salami frankfurter tongue. Chislic burgdoggen pork loin alcatra porchetta jowl.  Venison andouille biltong jerky frankfurter chislic strip steak pork chop doner sirloin pork belly filet mignon.
Turducken doner ham hock boudin, pork kielbasa frankfurter ball tip pancetta. Pig spare ribs sirloin, kielbasa t-bone filet mignon turkey tongue kevin tri-tip pork loin ham andouille ribeye. Pork chop tenderloin short ribs, meatloaf pastrami fatback t-bone beef ball tip turducken pork cupim salami. Tongue porchetta t-bone landjaeger pork tail buffalo boudin. Pig boudin flank, swine pork belly meatball jowl pastrami. Swine fatback jowl filet mignon spare ribs venison. Strip steak cupim swine ball tip chislic, shank burgdoggen t-bone beef pastrami brisket.
Picanha tri-tip leberkas short loin kielbasa cow tongue buffalo sirloin chicken salami. Tri-tip pork loin pork chop ribeye, tongue pancetta kevin beef ribs chislic boudin frankfurter picanha. Shoulder short ribs ribeye cupim strip steak. Sirloin salami flank, fatback jowl cow tongue ham hock capicola alcatra shank porchetta. Meatloaf picanha bresaola salami buffalo.


Tenor on Arweave
UPLOAD
LOGIN
Tag Name
Upload Your Gif
Click to add Gif
Upload
Latest GIFs
Login
×
Drop a keyfile to login
New Gif Post
×
Transaction Fee:
Tag:
You need to enable JavaScript to run this app


Klangmeister is a live coding environment for the browser. It lets you design synthesisers and compose music using computer code - without having to install anything on your own computer.


I work in the community health practice under the direct supervision of one or more prescribers who themselves
have been approved for access to PharmaNet. My employment duties require me to access PharmaNet and information
from PharmaNet to support the prescribers to deliver direct patient care in the scope of their, and my own,
professional practice, to individuals whose PharmaNet record I am accessing.
I hereby acknowledge that I agree with the following statements and undertakings:
-
I acknowledge that I may only access PharmaNet to the extent necessary to provide health services to, or to
facilitate the care of, the individual whose personal information is being accessed, and only in a form and
manner of access that is consistent with the conformance or compliance standard relating to PharmaNet and any
other policies or procedures required by the Province.
-
I understand that my access to PharmaNet and use of information from PharmaNet are subject to applicable law,
including:
-
the Pharmaceutical Services Act and
-
the Freedom of Information and Protection of Privacy Act.
-
I understand that the Province may, in writing and from time to time, set limits and conditions in respect of
personal information disclosed from PharmaNet and that I must comply with them.
-
I will only access PharmaNet as directed by the prescriber(s) supervising me at the time.
-
I will complete all training required by the Pharmacy’s PharmaNet software vendor and the Province before
accessing PharmaNet.
-
I will maintain all personal information accessed by me or disclosed to me from PharmaNet in confidence, unless
I am required to disclose the information
-
for the purposes of providing direct patient care to individuals whose PharmaNet record I am accessing, or
-
as otherwise permitted under the Pharmaceutical Services Act.
-
I will protect all personal information accessed by me or disclosed to me from PharmaNet by making reasonable
security arrangements against such risks as unauthorized access, collection, use, disclosure or disposal of
information, files or records containing personal information from PharmaNet.
-
I will not:
-
permit any person to use any user IDs, passwords or credentials provided to me to access PharmaNet;
-
divulge, share or compromise any user IDs, passwords or credentials;
-
use or attempt to use the user ID, password or credential of any other person;
-
test or examine the security related to PharmaNet;
-
take any action that might reasonably be construed as compromising the integrity of PharmaNet, its
information, or the provincial drug plan;
-
alter the format or content of a print or display of any information contained within PharmaNet; or
-
access PharmaNet from any location other than inside the community pharmacy listed above.
-
I understand that if I breach the terms of this Undertaking, in addition to any legal remedy that the Province
may have against me:
-
the Province may notify my employer in respect of any suspected inappropriate access to PharmaNet by me, and
-
my access to PharmaNet may be suspended or terminated.
-
I understand that at any time at the discretion of the Province:
-
I may be required to renew this undertaking or sign a revised undertaking;
-
my access to PharmaNet may be suspended or terminated as permitted under the Pharmaceutical Services Act.


Returns CheckpointState proto from the "checkpoint" file.
tf.compat.v1.train.get_checkpoint_state
tf.compat.v2.train.get_checkpoint_state
tf.train.get_checkpoint_state( checkpoint_dir, latest_filename=None )
If the "checkpoint" file contains a valid CheckpointState proto, returns it.
checkpoint_dir
: The directory of checkpoints.latest_filename
: Optional name of the checkpoint file. Default to
'checkpoint'.A CheckpointState if the state was available, None otherwise.
ValueError
: if the checkpoint read doesn't have model_checkpoint_path set.


{% extends "view/rootpage.html" %} {% block title %}Tournatrack Directory{% endblock %} {% block content %}
This last may not be completely live, changes may take some time to propagate


@Service
public class UserService
extends java.lang.Object
| Constructor and Description |
|---|
UserService(UserRepository userRepository,
BuildingRepository buildingRepository) |
| Modifier and Type | Method and Description |
|---|---|
boolean |
canComment(long buildingId)
Checks if user has ability to comment on a malfunction.
|
void |
checkCanSupervise(User user,
long buildingId)
Checks if user can be a supervisor of a building.
|
void |
checkIsUsernameUnique(java.lang.String username)
Checks if username is unique.
|
java.util.List<User> |
findAll()
Gets all users.
|
User |
findById(long id)
Gets a user by its ID.
|
User |
findByUsername(java.lang.String username)
Gets a user by its username.
|
Company |
findCompanyById(long id)
Gets a company by its ID.
|
User |
findCurrentUser()
Gets a user currently logged in.
|
Tenant |
findTenantById(long id)
Gets a tenant by its ID.
|
boolean |
hasAccessTo(long buildingId)
Checks if current user is either a supervisor or a tenant of a building.
|
boolean |
isAssigneeOf(Malfunction malfunction)
Checks if user is assignee of a malfunction.
|
boolean |
isCompanyOf(long buildingId)
Checks if current user is company assigned to a building.
|
boolean |
isCreatorOf(Announcement announcement)
Checks if user is creator of a announcement.
|
boolean |
isCreatorOf(Malfunction malfunction)
Checks if user is creator of a malfunction.
|
boolean |
isSupervisorOf(long buildingId)
Checks if current user is supervisor of a building.
|
boolean |
isTenantOf(long buildingId)
Checks if current user is tenant of a building.
|
boolean |
usernameTaken(java.lang.String username)
Checks if username is taken.
|
@Autowired public UserService(UserRepository userRepository, BuildingRepository buildingRepository)
public boolean canComment(long buildingId)
buildingId
- building IDpublic void checkCanSupervise(User user, long buildingId)
BadRequestException
is thrown.user
- user IDbuildingId
- building IDpublic void checkIsUsernameUnique(java.lang.String username)
BadRequestException
is thrown.username
- usernamepublic java.util.List<User> findAll()
public User findById(long id)
id
- user IDpublic User findByUsername(java.lang.String username)
username
- usernamepublic Company findCompanyById(long id)
id
- company IDpublic User findCurrentUser()
ForbiddenException
.public Tenant findTenantById(long id)
id
- tenant IDpublic boolean hasAccessTo(long buildingId)
buildingId
- building IDpublic boolean isAssigneeOf(Malfunction malfunction)
malfunction
- malfunctionpublic boolean isCompanyOf(long buildingId)
buildingId
- building IDpublic boolean isCreatorOf(Announcement announcement)
announcement
- announcementpublic boolean isCreatorOf(Malfunction malfunction)
malfunction
- malfunctionpublic boolean isSupervisorOf(long buildingId)
buildingId
- building IDpublic boolean isTenantOf(long buildingId)
buildingId
- building IDpublic boolean usernameTaken(java.lang.String username)
username
- username


5. FAQ¶
5.1. Why netscud?¶
Very few changes from netdev (the first serious network device async python library created by Sergey Yakovlev) recently pushes me to create netscud. It cannot challenge netdev - I am far from an expert in developpement - but it has nice features I needed. Other people may need them. It is above all a personal challenge.
netdev github site can be found at: https://github.com/selfuryon
5.2. A short description of netscud?¶
netscud is like netdev (Ayns SSH) + napalm (API) + nornir (Inventory + concurrency function) in one package.
5.3. When is it interesting to use non-blocking technique like async?¶
It is interesting when there are commands send concurrently on more than 1 device and when using threads or processes is not wanted. In that configuration speed is fast and there is less troubles than managing race conditions on resources with locks.
5.4. Why the name netscud?¶
netscud purpose is to be fast like a rocket.
Also it is inspired by netdev async library coming from Russia; so it is recognition of the work done by the author of netdev.
And finally I needed a name not already used by a python library.


§255D-3 Authority to participate in multistate negotiations. For the purposes of reviewing or amending the agreement embodying the simplification requirements in section 255D-6, the State may enter into multistate discussions. For purposes of these discussions, the State shall be represented by the department. [L 2003, c 173, pt of §2; am L Sp 2005, c 3, §3]


{{ page.title }}
23 years experience in UX Design, Web Site/Application Development, and Product Marketing. Excellent analytical design skills. Diverse background with an emphasis in creative problem solving, cross-departmental communication and customer-focused, results oriented solutions. I'm a highly curious individual who gets excited about product design and developing delightful solutions for users. People shouldn't have to put up with crummy software. Whether I'm doing UX work or building applications, I want to make people's tasks effortless and engaging.
Areas of Expertise
- User Experience Design (UX)
- Information Architecture analysis & design
- Wireframing and prototying
- Sketch, Figma, Framer, Axure, Omnigraffle and other related wireframing & prototyping tools
- Adobe Creative Suite including Photoshop, Illustrator, XD, and InDesign
- HTML, CSS (love CSS Grid!), JavaScript, jQuery
- Communication skills, especially cross-departmental
- Experienced working in Lean UX, Agile environments
- Requirements gathering
- Creative problem solving
- User-focused solutions
- Experience with Salesforce.com
- Confident with project management tools like Jira, Trello, Slack, and HipChat
Employment History
DAT Solutions — Mar. 2012–Sep. 2017
DAT is the industry leader in freight matching and rate forecasting for the trucking industry.
Senior UX Interaction Designer
I primarily worked on the company’s flagship freight matching product, DAT Power, and the highest volume product, DAT TruckersEdge. DAT Power was a new web-based product redesigned from a Windows-based product. Moving from a native client to a web application introduced many constraints which required new solutions.
Next I worked on the company’s iOS and Android freight matching products. Again, new constraints which required new designs. A lot of data needed to be shown in a small space. Since we did both iOS and Android, the designs had to be modified to feel natural on each platform.
My final project was to rebuild the low-end freight matching product using Material Design. In some ways this was the most challenging design because it had the most business constraints. Some features were brought in from higher-end products, but they had to be modified so as to not compete with the other products.
In these roles, I was responsible for conceptual design of features, helping product owners refine their vision, and wireframes and prototypes to hand off to visual design and development. Basically my job was to quickly iterate on ideas, be they mine or someone else’s, and evaluate and select the best options before we had to commit expensive development resources. In the process of evaluation, I used a variety of tools to examine ideas and communicate back to the team
Site9 - 2007–2012
Site9 was a venture-funded startup, now owned by Astound Commerce. Their product began as a content management system for e‑commerce websites and evolved into ProtoShare.com, an online, collaborative website prototyping tool targeted towards the UX Design and Information Architecture spaces. Being a startup, the team was small, so I had oversight across multiple departments.
Senior Web Developer
Used Site9‘s CMS to develop client websites which involved extensive hand-coding of HTML, CSS and JavaScript. Responsible for designing and maintaining the corporate ProtoShare.com websites (main site, blog, forum). This entailed hand-coding HTML, CSS and JavaScript, designing layout, graphics, forms, video and content. Produced the product tour video in-house instead of outsourcing it, saving $10,000 over two years (which equates to about 10% of Marketing’s monthly budget). Contributed various icons and graphics and CSS expertise to the ProtoShare application.
Product Marketing Manager
Responsible for strategic messaging for ProtoShare.com. Duties included preforming competitive market research of the UX community, formulating pricing strategies, evaluating application usability, and providing real world customer-focused feedback (because I was using our product to do actual UX design of our websites) on product direction. Developed marketing materials including blog posts, videos, graphics, release notes, and example content for inclusion with the ProtoShare.com application. Tracked and reported on application stats. Conducted ongoing product testing, verifying user issues, and defect analysis and reporting.
Salesforce.com Developer/Administrator
Planned and managed initial roll out for the sales team. Worked with Engineering on back-end integration with ProtoShare.com using Apex for reporting on sign-up and billing functions. One highlight was using Salesforce.com email handlers to respond to ProtoShare.com application events such as new and cancelled accounts, freeing up value Engineering resources. Developed a custom VisualForce sales dashboard using SOQL queries and HTML/JavaScript which tracked many variables regarding trials and customers, keeping everyone on the same page.
Kentrox - 1990-2007
Salesforce.com Admin & Senior Web Developer — 2001–2006
As the primary Salesforce.com system administrator, led a cross-departmental team of three other administrators. Was the go-to person for technical problems and research. Integrated legacy databases and did customization work where needed.
Managed multiple websites, internal, external and partner. Produced specialty marketing campaigns, including a highly regarded custom Excel-based product configurator and weekly activity newsletter for the sales team. Designed the first web-based UI for Kentrox’s router products. Did product photography for web and print.
Web Developer — 1996–2001
Developed Kentrox’s first website as a side project in 1994. Transitioned to full time management of a four person web team in 1996. During this time Kentrox launched a B-to-B eCommerce site and grew the web site from a simple product site to one including support and partner portals. Responsible for training new employees in web technologies.
Information Engineer — 1994–1996
Specialist in the Technical Publications department responsible for documenting complex network management products. Received outstanding work award for my innovate documentation solution for network management software and comprehensive 300+ page reference materials.
Software Engineer — 1990–1994
Developed network management software, specifically responsible for a middle-ware PC-based application which translated between device command-line interfaces and the Simple Network Management Protocol (SNMP).
Education
Washington University in St. Louis — B.S. Software Engineering, 1990
Skills
- 23+ years experience developing websites and web applications.
- Proficient in HTML, CSS, JavaScript.
- Proficient in Information Architecture, User Experience Design, and usability testing.
- Proficient with wireframing and prototyping tools (Sketch, Figma, Axure, InVision).
- Proficient with the Adobe Creative Suite (Photoshop, Illustrator, XD, InDesign).
- Proficient with product management tools (Jira, Trello, Slack, HipChat).
- Working knowledge of other prototyping tools (Framer, Principle).
- Working knowledge of WordPress, PHP, Jekyll, mySQL.
- Working knowledge of Google's Material Design guidelines.
- Working knowledge of iOS and Android design and development.
- Experience with Salesforce.com administration and development.
- Expert on both PC and Mac platforms.
- Creative problem solver with an emphasis on user-focused solutions.
- Excellent communication skills, especially bridging design, development, and marketing.
- Very comfortable working in a cross-departmental team role.
Portfolio
Skills I'm current improving
- iOS & Mac application development
- Node JS, REST API development
- More JavaScript, CSS (Sass specifically), and HTML


| | |
- cosine_similarity(thread, text)
- Get cosine similarity between two comments.
- count_occurances(comment, word)
- A helper function to get the number of words in a comment.
- topic_importance(thread)
- Returns topic importance value of a built thread in a topic clutser.
- topic_measure(word)
- This method takes in a word and returns the expected value of topic measures for the word from all the topic clusters constructed in the given blog.
|


I'm Vikash Kumar, working @Grab. When I am not building Grab or working on personal projects, I like reading business books and biographies, understanding business side of tech and startups. Hope to use the knowledge some day.
This website contains my learnings, notes and projects.
Tried user authentication on App Engine, Google's PaS. Let's figure out!
Android: getLastLocation() returning nullUnderstanding how to debug and get user's last location on Android.
I also read and recommend a lot on Medium.
Wrote a simple and lightweight blogging platform build on GCP, ideal for dev or personal bloggers.
You can find my other projects at Github.


Breakpoints
| Range (px) | Window | Columns | Margins/ Gutters (px) |
|---|---|---|---|
| 0 - 599 | xs | 12 | 16 |
| 600 - 1023 | sm | 12 | 24 |
| 1024 - 1439 | md | 12 | 24 |
| 1440 - 1919 | lg | 12 | 24 |
| 1920 + | xl | 12 | 24 |
The responsive grid consists of rows and columns. Depending on the screen width these may change.
For making the responsive grid. The CSS grid system is used.
| Range (px) | Window | Columns | Margins/ Gutters (px) |
|---|---|---|---|
| 0 - 599 | xs | 12 | 16 |
| 600 - 1023 | sm | 12 | 24 |
| 1024 - 1439 | md | 12 | 24 |
| 1440 - 1919 | lg | 12 | 24 |
| 1920 + | xl | 12 | 24 |
.container
. The container is mainly used for giving a size to the content of the page.
By default the container is smaller than the screen but when you add the class .container--fluid
you can make the container fullscreen.
| Window | Class | Result |
|---|---|---|
| xs | xs1 - xs12 | Element width |
| start-xs1 - start-xs12 | Column starting position | |
| xs__text--(right, left or center) | Text alignment | |
| xs-(only, up, and-down)-(show, hide) | Show/ hide element | |
| sm | sm1 - sm12 | Element width |
| start-sm1 - start-sm12 | Column starting position | |
| sm__text--(right, left or center) | Text alignment | |
| sm-(only, up, and-up, down, and-down)-(show, hide) | Show/ hide element | |
| md | md1 - md12 | Element width |
| start-md1 - start-md12 | Column starting position | |
| md__text--(right, left or center) | Text alignment | |
| md-(only, up, and-up, down, and-down)-(show, hide) | Show/ hide element | |
| lg | lg1 - lg12 | Element width |
| start-lg1 - start-lg12 | Column starting position | |
| lg__text--(right, left or center) | Text alignment | |
| lg-(only, up, and-up, down, and-down)-(show, hide) | Show/ hide element | |
| xl | xl1 - xl12 | Element width |
| start-xl1 - start-xl12 | Column starting position | |
| xl__text--(right, left or center) | Text alignment | |
| xl-(only, and-up, down)-(show, hide) | Show/ hide element |

12 columns

4 columns

4 columns

4 columns

6 columns

6 columns

6 columns

3 columns

3 columns

start 7 rendered 1

start 1 rendered 2


SessionRejectReason (373)
Code to identify reason for a session-level Reject message.
Type: int
| 0 | Invalid Tag Number |
| 1 | Required Tag Missing |
| 4 | Tag specified without a value |
| 5 | Value is incorrect (out of range) for this tag |
| 6 | Incorrect data format for value |
| 9 | CompID problem |
| 10 | SendingTime Accuracy Problem |
| 11 | Invalid MsgType |
| 13 | Tag appears more than once |
| 16 | Incorrect NumInGroup count for repeating group |
| 18 | Invalid/Unsupported Application Version |
| 99 | Other |


Study
Barrett 2013
Rodriguez 2014
Taunton 2014
Zhang 2018
Overall (I-squared = 86.8%, p = 0.000)
P=0.030
NOTE: Weights are from random effects analysis
oS
WMD (95% Cl)
4.10 (0.10, 8.10)
3.00 (—1.12, 7.12)
4.00 (-1.61, 9.61)
—+— 16.02 (11.60, 20.44)
6.80 (0.64, 12.95)
%
Weight
25.81
25.64
23.35
25.20
100.00
T —20.4
20.4


Add the URLs of PodCast feeds you would like to track here.
Type or paste in an URL for a valid xml RSS feed.


Documentation
Integrations
Support
Playground
Blog
Twitter
Slack
GitHub
Open Policy Agent Support
Below is a list of companies that offer commercial support and other enterprise offerings for Open Policy Agent
Styra is the original creator of Open Policy Agent and provides support, professional services, training, and enterprise products.


The C-Word - talking Calculus with Steven Strogatz — Numberphile This is Numberphile. We mainly post videos about mathematics and just numbers in general.
Mid Century Themes (Dark / Light) - Visual Studio Marketplace A mid-century inspired set of themes for Visual Studio.
dotnet/core Home repository for .NET Core. Contribute to dotnet/core development by creating an account on GitHub.
ASP.NET Blog | Setting HTTP header attributes to enable Azure authentication/authorization using HTTPRepl Posted on behalf of Ahmed Metwally The HTTP Read-Eval-Print Loop (REPL) is a lightweight, cross-platform command-line tool that’s supported everywhere .NET Core is supported. It’s used for making HTTP requests to test ASP.NET Core web APIs and view th...
Locknote: The Internet of Pwned Things - Troy Hunt If it connects, it can be pwned! As much as we may love IoT, it introduces all new vulnerabilities in places we've never before seen them. We're collecting classes of data that have never been digitised before, storing it on the cloud and opening up contr...
dotnet/winforms Windows Forms is a .NET Core UI framework for building Windows desktop applications. - dotnet/winforms
prefers-color-scheme The prefers-color-scheme CSS media feature is used to detect if the user has requested the system use a light or dark color theme.
Test web APIs with the HTTP REPL Learn how to use the HTTP REPL .NET Core Global Tool to browse and test an ASP.NET Core web API.
Joining the .NET Foundation Maturity Model Pilot | .NET Blog Joining the .NET Foundation Maturity Model Pilot The .NET Foundation is starting a new pilot program to increase quality and user confidence in open source projects, using a new project maturity model. We’ve been working with the Technical Review Action G...
Alexis Kennedy I work at Failbetter Games. These days, I’m CEO. But I worked here for five years before that, and from when I joined in January 2014…
ASP.NET Blog | ASP.NET Core and Blazor updates in .NET Core 3.0 ASP.NET Core and Blazor updates in .NET Core 3.0 Today we are thrilled to announce the release of .NET Core 3.0! .NET Core 3.0 is ready for production use, and is loaded with lots of great new features for building amazing web apps with ASP.NET Core and B...
.NET Videos | Free videos from the .NET team and community Free videos for learning all aspects of the .NET developer platform, including web, mobile, desktop, C#, machine learning, containers/docker, and data access.
AWS Joins the .NET Foundation | Amazon Web Services Fred Wurden, General Manager of AWS Windows and Enterprise and Norm Johanson, Senior Software Dev Engineer, AWS SDKs and Tools We’re excited to announce today that AWS is joining the .NET Foundation as a corporate sponsor. AWS has a long-standing commitme...
dotnet/docs This repository contains .NET Documentation. Contribute to dotnet/docs development by creating an account on GitHub.
dotnet/core Home repository for .NET Core. Contribute to dotnet/core development by creating an account on GitHub.
Announcing .NET Core 3.0 | .NET Blog Announcing .NET Core 3.0 We’re excited to announce the release of .NET Core 3.0. It includes many improvements, including adding Windows Forms and WPF, adding new JSON APIs, support for ARM64 and improving performance across the board. C# 8 is also part o...
.NET Videos | Free videos from the .NET team and community Free videos for learning all aspects of the .NET developer platform, including web, mobile, desktop, C#, machine learning, containers/docker, and data access.
Announcing F# 4.7 | .NET Blog We’re excited to announce general availability of F# 4.7 in conjunction with the .NET Core 3.0 release! In this post, I’ll show you how to get started, explain everything in F# 4.7 and give you a sneak peek at what we’re doing for the next version of F#.
Upgrade to 3.0 RTM packages and SDKs by NickCraver · Pull Request #426 · MiniProfiler/dotnet This bumps versioning off pre-release packages for the .NET Core 3.0 release today.
“UPSERT” Race Condition With MERGE I mentioned in Conditional INSERT/UPDATE Race Conditionthat most “UPSERT” code is defective and can lead to constraint violations and data integrity issues in a multi-user environment .In this post, I’ll show how to prevent duplicate key errors and data p...
Prevent users registering with passwords from data breaches It is generally recommended that developers of web applications ensure their users pick decent passwords. This often means ensuring a minimum length, preventing common passwords, or words from the dictionary. Sometimes users need to mix and match var...
Troy Hunt Returns to Denmark When dealing with security and preventing data breaches, the process starts with understanding people and how people think ...
dotnet-presentations/aspnetcore-app-workshop This workshop will teach you ASP.NET Core by building a complete conference management website from scratch. - dotnet-presentations/aspnetcore-app-workshop
Chocolatey's Website Gets a Long Awaited Redesign! Chocolatey is software management automation for Windows that wraps installers, executables, zips, and scripts into compiled packages. Chocolatey integrates w/SCCM, Puppet, Chef, etc. Chocolatey is trusted by businesses to manage software deployments.
Creature Keeper Combat Teaser Creature Keeper is an action adventure RPG with a strong focus on combat and exploration. Learn about the creatures of the world as you tame and fight alongside them. The more you learn about them, the more powerful you become. Make sure to check out th...


If you're reading this, at some point you will have come across the CSS property "Position"
position: relative;
position: absolute;
position: fixed;
What is position? and what do these values mean and how do they behave you may be asking? Keep reading to find out
Position is exactly that, the position of a an object on the page. If you think about any object on a website it has a position. Take the following list for example.
You look at a list, especially a numbered list like the one above and you may say, "well obviously the first item is at the top, why do I need a property for that?", and this is an excellent question.
The purpose of the position property, is not to identify where an object is, it is to be able to put the position where you want it to go, and the value you select for it controls how that effects the rest of the page.
A key thing to know when dealing with the position property, is that once you apply a position property to an object it is moved out of the "flow" of the web page. An example of this is if you had a magazine article and you cut a picture out of the page. You could put the image in the exact same place as you cut it out, or you could put it anywhere on the page or even completely off the page. You are able to put the image you have cut anywhere you want without affecting the rest of the page. This is what using the position property achieves on a website.
Every object takes up a certain amount of real estate on your screen. Take these photos of a ridiculously cute kitten
They are both positioned normally without having any css positioning applied to them. They both take up the same amount of space, and as html is displaying them natively they simply sit next to one another.
But what if I wanted the photo's to be at different places? I could use relative positioning. Relative positioning shifts an objects location on the page relative to it's starting position. So if I wanted to move the second cat photo down and to the left I would use the following code
/* Set position to be determined relatively */
position: relative;
/* Move the object down 30 pixels from where it started */
top: 30px;
/* Move the object 30 pixels to the right starting from it's left hand edge. */
left: 30px:
Below you can see the effect of this code when applied to just the first cute kitten.
As you can see, the first kitten photo has been moved down 30 pixels and to the right 30 pixels. The thing that you should also notice, is that the padding around the image is now different, with the right of the image sticking out past the side of the box. This is because as I mentioned above with the magazine example, it is as if you have cut the image out and you are moving it around above the page. So the hole where the image came from is still there, and any padding or margin on the object are still applied to where the hole is, but the image itself is able to be put anywhere with the instructions moving the image from it's original position.
Absolute positioning is very similar to Relative positioning with a simple difference. Positioning an object absolutely completely removes it from it's location on the page and positions it at the specified locations relative to the page.
There is an image in this div.
Don't believe me? View the source.
Did you find the image from the box above? Here's the source code for the box

There is an image in this div.
Don't believe me? View the source.

So why can you not see the image? Why is there only the text visible? The answer to both of these is because the image is absolutely positioned. Below I'll show you the css, as well as the image positioned normally.
The CSS
.absolute {
position: absolute;
top: 0px;
right: 0px;
}
The image
Have you seen that image before? Did you follow the code to figure it out? The image is positioned absolutely, on the top right corner of the page. You saw it when you first loaded the page. I told you it would make sense later.
From this example you can see exactly how absolute positioning works. Even though the image was located inside the first div, you could see no trace of it there. Being absolutely positioned removes the entire object from the page, and places it where you specify. The difference between relative positioning and absolute, is unlike relative positioning the other objects in page, move into the place that was previously occupied by the absolute object. Which is why there was no space where the picture came from in the example div.
Fixed positioning works almost identically to absolute positioning. It completely removes the object from flow, and the rest of the page fills in the gap. It then places the object where you tell it. The difference however lies in the fact that a fixed objects position is relative to the screen not the webpage.
"What's the difference between the screen and the webpage?" you may ask, The difference is, the screen is always the screen. The dimensions do not change (unless you resize your window), the top of the screen is always the top, the bottom is always the bottom. No matter how far you scroll on a web page, the bottom of the screen is still the bottom of the screen.
"Okay sure so the screen and the webpage are different. But what does that mean to me?" is yet another excellent question. Remember how in the Absolute example there is the image attached to the top right corner of the page? What happened to that image when you scrolled down? It disappeared, it scrolled off the top of the page as you would expect.
However look at the bottom right of your screen. Do you see a white arrow pointing up on a purple square? What happens when you scroll around the page? Does it disappear? As you have just seen happen, no matter how far you scroll that little purple box stays stuck to the bottom of your screen. It is always there, it is Fixed in place.
The code used on that little tab to get it to stay there is below.
/* Set element to have a fixed position */
position: fixed;
/* Set element to have the bottom attached to the bottom of the screen */
bottom: 0px;
/* Set element to be 5% of the width of the viewport in from the right hand side */
right: 5vw;
I hope that you enjoyed reading this and have formed a stronger understanding on what the css position property does, and how to use it.
Cute Kitten Photos by Ramiz Dedaković and Nine Köpfer on Unsplash