Phase 0 - Week 6 Functional Programming vs Object Oriented Design
Sunday, June 7, 2015
In researching the differences between Functional and Object Oriented Programming styles, I found that there are two very different opinions on which is better. For the purpose of this Blog, I will talk about some of the advantages and disadvantages for both; however, one common theme is that Object Oriented Design makes it easier to make changes and reuse code. In the visual representation below, you will see the basic structure for both Functional and Object Oriented Design
Functional Programming
In computer science, functional programming is a programming paradigm — a style of building the structure and elements of computer programs — that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. The programs are made up of functions. Functions are often not reusable. It is very difficult to copy a function from one program and reuse in another program because the the function is likely to reference the headers, global variables and other functions. In other words, functions are not well-encapsulated as a self-contained reusable unit.
Advantages
- Smaller Size - Object Oriented Programs tend to be much larger
- Require Less Effort - Object Oriented Programs require a lot more work to create
- Speed - Because Functional Programs are smaller and generally require less system resources
Disadvantages
- Generally more difficult to pick up for new coders.
- Functional idioms often do lots of inversion-of-control or laziness, which often has a negative impact on debugging
- It doesn't match the hardware as well
Object Oriented Programming
Object-oriented programming (OOP) is a programming language model organized around objects rather than "actions" and data rather than logic. Historically, a program has been viewed as a logical procedure that takes input data, processes it, and produces output data.
- The basic unit of OOP is a class, which encapsulates both the static attributes and dynamic behaviors within a "box", and specifies the public interface for using these boxes. Since the class is well-encapsulated (compared with the function), it is easier to reuse these classes. In other words, OOP combines the data structures and algorithms of a software entity inside the same box.
- OOP languages permit higher level of abstraction for solving real-life problems. The traditional procedural language (such as C and Pascal) forces you to think in terms of the structure of the computer (e.g. memory bits and bytes, array, decision, loop) rather than thinking in terms of the problem you are trying to solve. The OOP languages (such as Java, C++, C#) let you think in the problem space, and use software objects to represent and abstract entities of the problem space to solve the problem.
Advantages
- Code Reuse and Recycling: Objects created for Object Oriented Programs can easily be reused in other programs
- Encapsulation (part 1): Once an Object is created, knowledge of its implementation is not necessary for its use. In older programs, coders needed understand the details of a piece of code before using it (in this or another program)
- Encapsulation (part 2): Objects have the ability to hide certain parts of themselves from programmers. This prevents programmers from tampering with values they shouldn't. Additionally, the object controls how one interacts with it, preventing other kinds of errors
- Design Benefits: Large programs are very difficult to write. Object Oriented Programs force designers to go through an extensive planning phase, which makes for better designs with less flaws. In addition, once a program reaches a certain size, Object Oriented Programs are actually easier to program than non-Object Oriented ones
- Software Maintenance: Programs are not disposable. Legacy code must be dealt with on a daily basis, either to be improved upon (for a new version of an exist piece of software) or made to work with newer computers and software. An Object Oriented Program is much easier to modify and maintain than a non-Object Oriented Program. So although a lot of work is spent before the program is written, less work is needed to maintain it over time
Disadvantages
- Size: Object Oriented programs are much larger than other programs. In the early days of computing, space on hard drives, floppy drives and in memory was at a premium. Today we do not have these restrictions
- Effort: Object Oriented programs require a lot of work to create. Specifically, a great deal of planning goes into an object oriented program well before a single piece of code is ever written. Initially, this early effort was felt by many to be a waste of time. In addition, because the programs were larger (see above) coders spent more time actually writing the program.
- Speed: Object Oriented programs are slower than other programs, partially because of their size. Other aspects of Object Oriented Programs also demand more system resources, thus slowing the program down.


Something on my Pi went south, iv managed to get it up and running again but im getting an error trying to load emoncms
Table 'emoncms1.users' doesn't exist
Fatal error: Call to a member function fetch_array() on a non-object in /var/www/emoncms/db.php on line 66
This is not surprising as iv had to install mysql from scratch and create the DB. But i thought the emoncms should create the DB tables if not found... Is this not so.?
any ideas.. Thanks.
Re: Re-setting up from a failed db install.
Did it allready worked or not, so is there any important data you need in the existing emoncms-Mysql database?
Are the database settings (/var/www/emoncms/settings.php) correct?
You can only try to delete the emoncms directory (with all included files in it) and the emoncms database im mysql. After that reinstall emoncms: http://openenergymonitor.org/emon/emoncms/installing-ubuntu-debian-pi
Then continue with the install here: http://wiki.openenergymonitor.org/index.php?title=Raspberry_Pi#RFM12BPi_...
Re: Re-setting up from a failed db install.
Thanks for that.. It was all working and some how the mysql got corrupt.. Iv removed it and reinstalled it and all seems to be ok now.. phpmadmin seems to work fine and i can see other dbs iv got on there..
just emoncms does not work..
The /var/......./settings.php are the same / tried a new db name that iv created eg step8 just it still fails. The error seems to point to the users table not the fact it cant get to the db..
Right just changed the settings file to a dummy database (thats does not exsist)
Warning: mysqli::mysqli(): (42000/1049): Unknown database 'emoncms11111' in /var/www/emoncms/db.php on line 41
Warning: mysqli::query(): Couldn't fetch mysqli in /var/www/emoncms/db.php on line 59
Warning: db_query(): Couldn't fetch mysqli in /var/www/emoncms/db.php on line 60
Fatal error: Call to a member function fetch_array() on a non-object in /var/www/emoncms/db.php on line 66
So that seems to point to the fact it cant see the db.
So edit to the correct db..
Table 'emoncms.users' doesn't exist
Fatal error: Call to a member function fetch_array() on a non-object in /var/www/emoncms/db.php on line 66
This seems to say the db is ok but the tables arnt there..
Any ideas.
Re: Re-setting up from a failed db install.
is $dbtest = true; in settings.php? it may be worth trying to insert this:
db_schema_setup(load_db_schema());
at line 29 of index.php
opening an emoncms page in the browser and then removing that line again, this will force a db update.
Trystan
Re: Re-setting up from a failed db install.
Thanks Trystan..
Seems the pi goes through memory cards quickly.. Set up a new card on the 28/12 and it ate its self today at 1012.
These are not cheap cards, EG sandisk cards. although from old cameras currently but they have not written millions of photos to them.
Anyway thanks again and the command does work.
Re: Re-setting up from a failed db install.
I've gone through two cards already myself since mid-December. I'm hoping it was a bad power supply - I've just changed plugs and I'm now doing daily backups of the database. It doesn't really take that long to get a system going from scratch with the pre-made SD card image though.
Nick
Re: Re-setting up from a failed db install.
I am on my fourth SD card and 2nd Raspberry Pi in the past month or so, trying to get emoncms to run stably. I tried out 3 or 4 power supplies.
Things would start out okay after a fresh OS and emoncms install. The system load average as reported by "uptime" would start at about 2.0, but after a couple days would be up around 4 to 5, and about then the system would crash. This all while running only emoncms. On restart all it would give was I/O errors. Some of the cards could be re-formatted and used again, but some I couldn't recover at all.
This high system load suggests to me that processes were waiting on I/O. Which was presumably SD card access.
Two of the SD cards were Kingston micro-SD 8GB class 4. Somewhere here I saw a note that suggested the performance of Kingston SD cards might not be good. I agree.
My fourth card which I just setup today is a Transcend class 10 8GByte, running in a 512MByte Pi rather than the 256MByte Pi I started with. So far so good. The power supply is now a linear bench power supply rather than a cheaper USB power supply. Response is fast at the console compared to the other cards, and system load average remains below 0.5.
So I am hopeful, but won't trust that I have a good system until it works for a few more days.
I know little about MySQL and databases, but I do wonder if there is some performance optimization that could be done. Time to do some reading.
On the plus side, I have gotten quite proficient at setting up Raspberry Pi's, and of course am enjoying the use of the whole OpenEnergyMonitor system.
-Ed


|
Sensor Fusion Library
0.4.0
Orientation sensing for Espressif (ESP32, ESP8266) processors
|
The hal_i2c.h file declares low-level interface functions for reading and writing sensor registers using I2C. More...
Go to the source code of this file.
Macros | |
| #define | I2C_ERROR_OK (0) |
Functions | |
| bool | I2CInitialize (int pin_sda, int pin_scl) |
| Initialize the I2C system at max clock rate supported by sensors. pin_sda and pin_scl indicate the pin numbers to which the I2C SDA and SCL lines of the sensors are connected. Pass -1 to use the default Arduino pins. More... | |
| bool | I2CReadByte (uint8_t address, uint8_t reg, uint8_t *destination) |
| bool | I2CReadBytes (uint8_t address, uint8_t reg, uint8_t *destination, int num_bytes) |
| bool | I2CWriteByte (uint8_t address, uint8_t reg, uint8_t value) |
| bool | I2CWriteBytes (uint8_t address, uint8_t reg, const uint8_t *value, unsigned int num_bytes) |
| int8_t | Sensor_I2C_Write_List (registerDeviceInfo_t *devInfo, uint16_t slaveAddress, const registerwritelist_t *pRegWriteList) |
| Write register data to a sensor. More... | |
| int32_t | Sensor_I2C_Read (registerDeviceInfo_t *devInfo, uint16_t slaveAddress, const registerReadlist_t *pReadList, uint8_t *pOutBuffer) |
| Read register data from a sensor. More... | |
| int32_t | Sensor_I2C_Read_Register (registerDeviceInfo_t *devInfo, uint16_t peripheralAddress, uint8_t offset, uint8_t length, uint8_t *pOutBuffer) |
The hal_i2c.h file declares low-level interface functions for reading and writing sensor registers using I2C.
| bool I2CInitialize | ( | int | pin_sda, |
| int | pin_scl | ||
| ) |
Initialize the I2C system at max clock rate supported by sensors. pin_sda and pin_scl indicate the pin numbers to which the I2C SDA and SCL lines of the sensors are connected. Pass -1 to use the default Arduino pins.
Returns true if successful, false if problem initializing I2C.
| int32_t Sensor_I2C_Read | ( | registerDeviceInfo_t * | devInfo, |
| uint16_t | slaveAddress, | ||
| const registerReadlist_t * | pReadList, | ||
| uint8_t * | pOutBuffer | ||
| ) |
Read register data from a sensor.
| [in] | pCommDrv | pointer to the I2C ARM driver to use |
| [in] | devInfo | The I2C device number and idle function. |
| [in] | slaveAddress | the I2C slave address to read from |
| [in] | pReadList | a list of one or more register addresses and lengths to read |
| [in] | pOutBuffer | a pointer of sufficient size to contain the requested read data |
| int8_t Sensor_I2C_Write_List | ( | registerDeviceInfo_t * | devInfo, |
| uint16_t | slaveAddress, | ||
| const registerwritelist_t * | pRegWriteList | ||
| ) |
Write register data to a sensor.
| [in] | pCommDrv | pointer to the I2C ARM driver to use |
| [in] | devInfo | The I2C device number and idle function. |
| [in] | slaveAddress | the I2C slave address to write to |
| [in] | pRegWriteList | a list of one or more register/value pairs to write |


A page with a layout and partials, but custom yields, or lambdas
Features
custom yields: off
layout: on
partials: on
lambdas: off


Christian Robertson designed the Roboto. Roboto has a dual nature. It has a mechanical skeleton and the forms are largely geometric. At the same time, the font features friendly and open curves. While some grotesks distort their letterforms to force a rigid rhythm, Roboto doesn’t compromise, allowing letters to be settled into their natural width. This makes for a more natural reading rhythm more commonly found in humanist and serif types.
License: Apache, Version 2.0
FF FI FL FFI
ff fi fl ffi


Click on a variable title to expand or collapse variable legend.
| {{variable.CID}}: {{variable.variable.name}} |
|
|
| {{environmental.CID}}: {{environmental.name}} |
|
|
| Language Classifications |
|
|
| Geographic Regions |
|
|
Choose a variable:
Double click the tree or scroll to zoom.
Note: trees have been pruned to display only societies present in D-PLACE.


Element index for package undefined_package
[ a ]
[ b ]
[ c ]
[ d ]
[ e ]
[ f ]
[ g ]
[ h ]
[ i ]
[ l ]
[ m ]
[ n ]
[ o ]
[ p ]
[ r ]
[ s ]
[ t ]
[ u ]
[ _ ]
_
- $_debug
- in file PEAR.php, variable PEAR::$_debug
Whether to enable internal debug messages.
- $_default_error_handler
- in file PEAR.php, variable PEAR::$_default_error_handler
Default error handler (callback) for this object, if error mode is PEAR_ERROR_CALLBACK.
- $_default_error_mode
- in file PEAR.php, variable PEAR::$_default_error_mode
Default error mode for this object.
- $_default_error_options
- in file PEAR.php, variable PEAR::$_default_error_options
Default error options used for this object when error mode is PEAR_ERROR_TRIGGER.
- $_error_class
- in file PEAR.php, variable PEAR::$_error_class
Which class to use for error objects.
- $_expected_errors
- in file PEAR.php, variable PEAR::$_expected_errors
An array of expected errors.
- $_suites
- in file HTML.php, variable PHPUnit_GUI_HTML::$_suites
- _checkDelExpect
- in file PEAR.php, method PEAR::_checkDelExpect()
This method checks unsets an error code if available
- _createArrayVariable
- in file Request.php, method Request::_createArrayVariable()
- _createNonArrayVariable
- in file Request.php, method Request::_createNonArrayVariable()
- _createVariable
- in file Request.php, method Request::_createVariable()
- _getFiles
- in file SetupDecorator.php, method PHPUnit_GUI_SetupDecorator::_getFiles()
- _getProcessedString
- in file Request.php, method Request::_getProcessedString()
- _PEAR
- in file PEAR.php, method PEAR::_PEAR()
Destructor (the emulated type of...). Does nothing right now, but is included for forward compatibility, so subclass destructors should always call it.
- _PEAR_call_destructors
- in file PEAR.php, function _PEAR_call_destructors()
- _prepareError
- in file HTML.php, method PHPUnit_GUI_HTML::_prepareError()
- _prepareFailure
- in file HTML.php, method PHPUnit_GUI_HTML::_prepareFailure()
- _preparePassedTests
- in file HTML.php, method PHPUnit_GUI_HTML::_preparePassedTests()
- _prepareResult
- in file HTML.php, method PHPUnit_GUI_HTML::_prepareResult()
top
top
top
top
d
- delExpect
- in file PEAR.php, method PEAR::delExpect()
This method deletes all occurences of the specified element from the expected error codes stack.
- display
- in file TemplateEngine.php, method TemplateEngine::display()
Mostra l'output del template.
- debug.tpl.php
- procedural page debug.tpl.php
top
top
top
g
- getBacktrace
- in file PEAR.php, method PEAR_Error::getBacktrace()
Get the call backtrace from where the error was generated.
- getCallback
- in file PEAR.php, method PEAR_Error::getCallback()
Get the callback function/method from an error object.
- getCode
- in file PEAR.php, method PEAR_Error::getCode()
Get error code from an error object
- getDebugInfo
- in file PEAR.php, method PEAR_Error::getDebugInfo()
Get additional debug information supplied by the application.
- getMessage
- in file PEAR.php, method PEAR_Error::getMessage()
Get the error message from an error object.
- getMode
- in file PEAR.php, method PEAR_Error::getMode()
Get the error mode from an error object.
- getStaticProperty
- in file PEAR.php, method PEAR::getStaticProperty()
If you have a class that's mostly/entirely static, and you need static
- getSuitesFromDir
- in file SetupDecorator.php, method PHPUnit_GUI_SetupDecorator::getSuitesFromDir()
Setup test suites that can be found in the given directory
- getType
- in file PEAR.php, method PEAR_Error::getType()
Get the name of this error/exception.
- getUserInfo
- in file PEAR.php, method PEAR_Error::getUserInfo()
Get additional user-supplied information.
- get_template_vars
- in file TemplateEngine.php, method TemplateEngine::get_template_vars()
Restituisce il contenuto di una variabile del template.
top
top
i
- isError
- in file PEAR.php, method PEAR::isError()
Tell whether a value is a PEAR error.
top
top
top
top
o
- OS_UNIX
- in file PEAR.php, constant OS_UNIX
- OS_WINDOWS
- in file PEAR.php, constant OS_WINDOWS
top
p
- $param
- in file Request.php, variable Request::$param
- PEAR
- in file PEAR.php, method PEAR::PEAR()
Constructor. Registers this object in $_PEAR_destructor_object_list for destructor emulation if a destructor object exists.
- PEAR
- in file PEAR.php, class PEAR
Base class for other PEAR classes. Provides rudimentary emulation of destructors.
- PEAR_Error
- in file PEAR.php, method PEAR_Error::PEAR_Error()
PEAR_Error constructor
- PEAR_Error
- in file PEAR.php, class PEAR_Error
- PEAR_ERROR_CALLBACK
- in file PEAR.php, constant PEAR_ERROR_CALLBACK
- PEAR_ERROR_DIE
- in file PEAR.php, constant PEAR_ERROR_DIE
- PEAR_ERROR_EXCEPTION
- in file PEAR.php, constant PEAR_ERROR_EXCEPTION
- PEAR_ERROR_PRINT
- in file PEAR.php, constant PEAR_ERROR_PRINT
- PEAR_ERROR_RETURN
- in file PEAR.php, constant PEAR_ERROR_RETURN
- PEAR_ERROR_TRIGGER
- in file PEAR.php, constant PEAR_ERROR_TRIGGER
- PEAR_OS
- in file PEAR.php, constant PEAR_OS
- PEAR_ZE2
- in file PEAR.php, constant PEAR_ZE2
- PHPUnit_GUI_HTML
- in file HTML.php, method PHPUnit_GUI_HTML::PHPUnit_GUI_HTML()
the current implementation of PHPUnit is designed
- PHPUnit_GUI_HTML
- in file HTML.php, class PHPUnit_GUI_HTML
- PHPUnit_GUI_SetupDecorator
- in file SetupDecorator.php, class PHPUnit_GUI_SetupDecorator
this decorator actually just adds the functionality to read the test-suite classes from a given directory and instanciate them automatically, use it as given in the example below.
- PHPUnit_GUI_SetupDecorator
- in file SetupDecorator.php, method PHPUnit_GUI_SetupDecorator::PHPUnit_GUI_SetupDecorator()
- popErrorHandling
- in file PEAR.php, method PEAR::popErrorHandling()
Pop the last error handler used
- popExpect
- in file PEAR.php, method PEAR::popExpect()
This method pops one element off the expected error codes stack.
- pushErrorHandling
- in file PEAR.php, method PEAR::pushErrorHandling()
Push a new error handler on top of the error handler options stack. With this you can easily override the actual error handler for some code and restore it later with popErrorHandling.
- PEAR.php
- procedural page PEAR.php
top
r
- raiseError
- in file PEAR.php, method PEAR::raiseError()
This method is a wrapper that returns an instance of the configured error class with this object's default error handling applied. If the $mode and $options parameters are not specified, the object's defaults are used.
- registerShutdownFunc
- in file PEAR.php, method PEAR::registerShutdownFunc()
Use this function to register a shutdown method for static classes.
- Request
- in file Request.php, class Request
Class Request Version 1.1.0 Author: Deepak Dutta, http://www.eocene.net Unrestricted license, subject to no modifcations to the line above.
- Request
- in file Request.php, method Request::Request()
- Request.php
- procedural page Request.php
top
top
top
top
|
|


69 Note that the halo you see while dragging onto the arrowheads is red instead of white, and covers the input slot as well as the arrowheads. And when you drop the expression onto the arrowheads, the words “input list:” are added to the block text and the arrowheads disappear (in this invocation only) to remind you that the list represents all of the multiple inputs, not just a single input. The items in the list are taken individually as inputs to the script. Since numbers is a list of numbers, each individual item is a number, just what sizes wants. This block will take any number of numbers as inputs, and will make the sprite grow and shrink accordingly: The user of this block calls it with any number of individual numbers as inputs. But inside the deﬁnition of the block, all of those numbers form a list that has a single input name, numbers. This recursive deﬁnition ﬁrst checks to make sure there are any inputs at all. If so, it processes the ﬁrst input (item 1 of the list), then it wants to make a recursive call with all but the ﬁrst number. But sizes doesn’t take a list as input; it takes numbers as inputs! So this would be wrong: C. Formal Parameters The rings around Procedure-type inputs have an arrowhead at the right. Clicking the arrowhead allows you to give the inputs to a block or script explicit names, instead of using empty input slots as we’ve done until now. The names #1, #2, etc. are provided by default, but you can change a name by clicking on its orange oval in the input names list. Be careful not to drag the oval when clicking; that’s how you use the input inside the ring. The names of the input variables are called the formal parameters of the encapsulated procedure. Here’s a simple but contrived example using explicit names to control which input goes where inside the ring: Here we just want to put one of the inputs into two different slots. If we left all three slots empty, Snap ! would not ﬁll any of them, because the number of inputs provided (2) would not match the number of empty slots (3).


| Id | Name | Age | Salary | Actions |
|---|---|---|---|---|
| {{empl.id}} | {{empl.employee_name}} | {{empl.employee_age}} | {{empl.employee_salary | currency:'USD'}} |
| Id | Name | Age | Salary | Actions |
|---|---|---|---|---|
| {{empl.id}} | {{empl.employee_name}} | {{empl.employee_age}} | {{empl.employee_salary | currency:'USD'}} |
Are you sure you want to delete this employee?
Loading...


7 references to LoadJobStreams
System.Management.Automation (7)
engine\remoting\client\Job.cs (7)
1088
LoadJobStreams
(); // for delayed loading
1124
LoadJobStreams
(); // for delayed loading
1160
LoadJobStreams
(); // for delayed loading
1193
LoadJobStreams
(); // for delayed loading
1229
LoadJobStreams
(); // for delayed loading
1264
LoadJobStreams
(); // for delayed loading
1300
LoadJobStreams
(); // for delayed loading


Manage and Monitor Your Docker Containers with Dry Tool in 5 Min
If you are looking out for a tool which can manage Docker & Docker Swarm, you really need to try out “Dry” tool. With close to 1500 stars in short span of time, this tool is a terminal application to manage both Docker Host & Docker Swarm Mode.It shows information about Containers, Images and Networks, and, if running a Swarm cluster, it shows information about Nodes, Service, Stacks and the rest of Swarm constructs. It can be used with both local or remote Docker daemons.
Besides showing information, it can be used to manage Docker. Most of the commands that the official Docker CLI provides, are available in dry with the same behaviour. also, it can also be used as a monitoring tool for Docker containers.Dry can be installed as a single binary and does not require external libraries.
Under this tutorial, I will show you how to get started with this tool to manage and monitor your Docker containers
Tested Infrastructure
| Platform | Number of Instance | Reading Time |
|---|---|---|
| Play with Docker | 1 | 5 min |
Pre-requisite
- Create an account with DockerHub
- Open PWD Platform on your browser
- Click on Add New Instance on the left side of the screen to bring up Alpine OS instance on the right side
Running Multiple containers in an interactive and detached mode.
[node1] (local<EMAIL_ADDRESS>~
$ docker pull busybox
Using default tag: latest
latest: Pulling from library/busybox
57c14dd66db0: Pull complete
Digest: sha256:7964ad52e396a6e045c39b5a44438424ac52e12e4d5a25d94895f2058cb863a0
Status: Downloaded newer image for busybox:latest
[node1] (local<EMAIL_ADDRESS>~
$ docker pull hello-world
Using default tag: latest
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:2557e3c07ed1e38f26e389462d03ed943586f744621577a99efb77324b0fe535
Status: Downloaded newer image for hello-world:latest
[node1] (local<EMAIL_ADDRESS>~
$ docker run -t -d busybox
7c96cde9894fd9ff42d1c3638cad65cf306cb2757b3925a925f4d421a510a79f
[node1] (local<EMAIL_ADDRESS>~
$ docker run -t -d hello-world
7a4198a31f61c380ddbe3b06eeb313da74de3d232727b0325937434900e8be8d
Verifying if containers are Up and Running:
$ docker ps
Verifying the exited containers
$ docker ps -a
Observe the below results:
[node1] (local<EMAIL_ADDRESS>~
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7c96cde9894f busybox "sh" 3 minutes ago Up 3 minutes romantic_greider
[node1] (local<EMAIL_ADDRESS>~
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7a4198a31f61 hello-world "/hello" 3 minutes ago Exited (0) 3 minutes ago stupefied_tu
7c96cde9894f busybox "sh" 3 minutes ago Up 3 minutes romantic_greider
Direct method
Running Dry tool in a single Shot
$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock moncho/dry
[node1] (local<EMAIL_ADDRESS>~
$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock moncho/dry
Unable to find image 'moncho/dry:latest' locally
latest: Pulling from moncho/dry
4fe2ade4980c: Pull complete
e9c4f9f2a7e3: Pull complete
28bab79b92a9: Pull complete
Digest: sha256:ad57f88f39fd910cc42e9416594dd2cf92ae561ddd914fd1c333f989a8d5bd4b
Status: Downloaded newer image for moncho/dry:latest
Interacting with Docker Containers:
Use the navigation keys mentioned below to interact with the terminal.
[H]:Help [Q]:Quit | [F1]:Sort [F2]:Toggle Show Containers [F5]:Refresh [%]:Filter |
[m]:Monitor mode [2]:Images [3]:Networks [4]:Nodes [5]:Services | [Enter]:Commands
Select any container from the list and hit [enter] to open the options:
Fetch logs
Inspect container
Kill container
Remove container
Restart
Show image history
Stats + Top
Stop
Verifying the Results
2.Interacting with Docker images:
- Press [2] to switch to Docker images. It will show a list of your Docker images.
- Select any image from the list and hit [enter] to show the details of the selected image.
You can use the shortcuts in Dry:
“Ctrl + D” to remove dangling. It is equivalent to docker volume rm with the flag dangling=true
“Ctrl + E” to remove image. It is equivalent to docker rmi.
“CTRL + F” to force remove. It is equivalent to docker rmi –force
3.Interacting with Docker Networks:
- Press [3] to switch to Docker networks. It will show a list of your active Docker networks.
- Select any network from the list and hit [enter] to fetch and show the details of the selected network. The output will look similar to the below:
Manual method
Download the latest version of Dry :
wget https://github.com/moncho/dry/releases/download/v0.9-beta.3/dry-linux-amd64
Moving the file to /usr/local/bin/dry
sudo mv dry-linux-amd64 /usr/local/bin/dry
Providing the access permissions.
sudo chmod 755 /usr/local/bin/dry
Check the version of Dry:
dry -v
Next, time to tun dry. Type dry in the command and hit [enter].
You should get the similar output where your containers are running.
Reference:
- https://github.com/moncho/dry
Contributor -
Sangam biradar -https://engineitops.com


Scotland v Israel, Slovakia v Ireland in Euro 2020 playoff semis
Scotland will face Israel in the Euro 2020 playoff semi-finals at Hampden Park, while Ireland visit Slovakia following a draw on Friday at UEFA headquarters in Switzerland.
REUTERS: Scotland will face Israel in the Euro 2020 playoff semi-finals at Hampden Park, while Ireland visit Slovakia following a draw on Friday at UEFA headquarters in Switzerland.
Steve Clarke's Scotland were assured a home match because they topped their group at the inaugural Nations League last year, and victory at Hampden Park on March 26 will see them visit either Norway or Serbia in the Path C playoff final.
Ireland, who already knew their opponents ahead of Friday's draw, could visit the winner of the match between Bosnia and Northern Ireland in the Path B final.
Iceland, who reached the Euro 2016 semi-finals, will host Romania in the Path A semi-final. The winner will need to beat Bulgaria or Hungary to secure progress to the main draw.
The four playoff winners will then join the 20 teams who have already qualified for the Euro 2020 finals to be held from June 12 to July 12.
For the first time, the Euro finals will be staged in 12 cities in 12 countries across Europe rather than the traditional system of one or two host nations.
The main draw for the competition will be held in Bucharest on Nov. 30, with each host nation to play in the group assigned to their stadium.
(Reporting by Hardik Vyas in Bengaluru; Editing by Andrew Cawthorne)


Package com.mypurecloud.sdk.v2.guest.model
package com.mypurecloud.sdk.v2.guest.model
-
ClassDescriptionCreateWebChatConversationRequestCreateWebChatConversationResponseCreateWebChatMessageRequestThe purpose of the message within the conversation, such as a standard text entry versus a greeting.DetailErrorBodyGuestMemberInfoJourneyActionJourneyActionMapJourneyContextJourneyCustomerJourneyCustomerSessionLimitGets or Sets namespaceWebChatConversationObject representing the guest model of a media request of a chat conversation.The state of the media request, one of PENDING|ACCEPTED|DECLINED|TIMEDOUT|CANCELLED|ERRORED.Gets or Sets typesWebChatGuestMediaRequestEntityListWebChatMemberInfoThe role of the member, one of [agent, customer, acd, workflow]The connection state of this member.WebChatMemberInfoEntityListWebChatMessageThe purpose of the message within the conversation, such as a standard text entry versus a greeting.WebChatMessageEntityListWebChatRoutingTargetThe target type of the routing target, such as 'QUEUE'.WebChatTyping


scrounger.utils.ios module
Module with ios utility functions.
""" Module with ios utility functions. """ from scrounger.utils.general import requires_binary from scrounger.utils.general import execute as _execute def devices(): """ Find connected iDevices :return: a list of idevice UDIDs and Names """ @requires_binary("lsusb") @requires_binary("grep") def _connected_devices(): from scrounger.utils.general import remove_multiple_spaces output = _execute("lsusb -v | grep -E \"idVendor|idProduct|iSerial\"") devices = {} # finds apple devices lines = iter(output.split("\n")) for vendor in lines: product, serial = next(lines, ""), next(lines, "") if "apple" in vendor.lower(): serial = serial.strip().rsplit(" ", 1)[-1] devices[serial] = remove_multiple_spaces( product).split(" ", 2)[-1] return devices return _connected_devices() def plist_to_dict(plist): """ Converts a plist file output to a python dictionary :param str plist: the output of a plist file :return: a dict with the plist contents """ import biplist return biplist.readPlistFromString(plist) def plist_dict_to_xml(plist, key=None): """ Converts a plist dict into an xml string :param dict plist: the plist to convert :param str key: if the key is set and in the plist it will be the only tag returned :return: an xml string containing the plist """ import plistlib if key and key in plist: plist = plist[key] xml = plistlib.writePlistToString(plist) return '\n'.join(xml.split('\n')[3:-2]) def otool_symbols(local_app_binary): """ Returns the symbols table from a local iOS app using otool :param str local_app_binary: the path to the app to get the symbols from :return: the symbols table """ @requires_binary("otool") def _otool_symbols(local_app_binary): # prepare binary local_app_binary = local_app_binary.replace(" ", "\ ") return _execute("otool -Iv {}".format(local_app_binary)) return _otool_symbols(local_app_binary) def jtool_symbols(local_app_binary): """ Returns the symbols table from a local iOS app using jtool :param str local_app_binary: the path to the app to get the symbols from :return: the symbols table """ @requires_binary("jtool") def _jtool_symbols(local_app_binary): # prepare binary and assume arm64 arch local_app_binary = local_app_binary.replace(" ", "\ ") arch = jtool_archs(local_app_binary)[-1] return _execute("jtool -S -arch {} {}".format(arch, local_app_binary)) return _jtool_symbols(local_app_binary) def otool_flags(local_app_binary): """ Returns the compilation flags from an iOS app using otool :param str local_app_binary: the path to the app to get the flags from :return: the flags """ @requires_binary("otool") def _otool_flags(local_app_binary): # prepare binary local_app_binary = local_app_binary.replace(" ", "\ ") return _execute("otool -hv {}".format(local_app_binary)) return _otool_flags(local_app_binary) def jtool_flags(local_app_binary): """ Returns the compilation flags from an iOS app using jtool :param str local_app_binary: the path to the app to get the flags from :return: the flags """ @requires_binary("jtool") def _jtool_flags(local_app_binary): # prepare binary and assume arm64 arch local_app_binary = local_app_binary.replace(" ", "\ ") arch = jtool_archs(local_app_binary)[-1] return _execute("jtool -v -h -arch {} {}".format(arch,local_app_binary)) return _jtool_flags(local_app_binary) def entitlements(local_app_binary): """ Returns entitlements of a binary app installed on ios :param str local_app_binary: the app to check the entitlements from :return: a dict with the entitlements """ @requires_binary("ldid") def _entitlements(local_app_binary): # prepare binary local_app_binary = local_app_binary.replace(" ", "\ ") ents_str = _execute("ldid -e {}".format(local_app_binary)) # fix multiple entitlements for multiple archs """ ents = "" for line in ents_str.split("\n"): if not line: break ents += line """ ents = "{}</plist>".format(ents_str.split("</plist>")[0]) return plist_to_dict(ents) return _entitlements(local_app_binary) def jtool_archs(local_app_binary): """ Get available archs from the binary :param str local_app_binary: the app to get the archs from :return: a list with the available archs """ import re archs = [] local_app_binary = local_app_binary.replace(" ", "\ ") archs_result = _execute("jtool -v -h {}".format(local_app_binary)) # check for multiple archs arch_no = re.findall(r"\d+\ architecture", archs_result) if len(arch_no) > 0: arch_no = int(arch_no[0].split(" ", 1)[0]) for arch in re.findall(r"arm(v6|v6s|v7|64)", archs_result): archs += ["arm{}".format(arch)] # for some reason jtool doesnt display arm64 if len(archs) < arch_no: archs += ["arm64"] return archs # only 1 arch return ["arm{}".format(arch) for arch in re.findall(r"arm(v6|v6s|v7|64)", archs_result.lower())] def otool_archs(local_app_binary): """ Get available archs from the binary :param str local_app_binary: the app to get the archs from :return: a list with the available archs """ import re # get flags flags = otool_flags(local_app_binary) return map(lambda arch: "arm{}".format(arch), re.findall(r"arm[ ]+(v6|v7|v7s|64) ", flags.lower())) def application_path(root_path): """ Given a root path try to identify the application's path returning the /path/to/Payload/App.app :param str root_path: path to start looking from :return: the path to the application or "" if not found """ if root_path.endswith("/"): root_path = root_path[:-1] if root_path.endswith(".app"): return root_path found_apps = _execute("find {} -name \"*.app\"".format(root_path)) return found_apps.split("\n")[0] def info(local_application_path): """ Retreived information about the application :param str local_application_path: application's path to get the information from :return: a dict with the information about the application """ return plist("{}/Info.plist".format(local_application_path)) def plist(local_file): """ Reads and returns a plist file in dict form :param str local_file: the plist list file to read :return: a dict with the plist content """ import biplist return biplist.readPlist(local_file) def unzip(local_ipa_file, target_path): """ Unzips an ipa file to target location :param str local_ipa_file: the file path to the IPA :param str target_path: the target path to unzip the app too :return: nothing """ @requires_binary("unzip") def _unzip(local_ipa_file, target_path): #clean path before _execute("rm -rf {}".format(target_path)) _execute("unzip -o {} -d {}".format(local_ipa_file, target_path)) _unzip(local_ipa_file, target_path) def otool_class_dump(local_app_binary): """ Dumps classes of an ios application using otool :param str local_app_binary: the application binary to dump classes from :return: a str with the output of otool """ @requires_binary("otool") def _otool_class_dump(local_app_binary): # prepare binary local_app_binary = local_app_binary.replace(" ", "\ ") return _execute("otool -ov {}".format(local_app_binary)) return _otool_class_dump(local_app_binary) def jtool_class_dump(local_app_binary): """ Dumps classes of an ios application using jtool :param str local_app_binary: the application binary to dump classes from :return: a str with the output of jtool """ @requires_binary("jtool") def _jtool_class_dump(local_app_binary): # prepare binary and assume arm64 arch local_app_binary = local_app_binary.replace(" ", "\ ") return _execute("jtool -v -d objc -arch arm64 {}".format( local_app_binary)) return _jtool_class_dump(local_app_binary) def save_class_dump(class_dump, local_file_path): """ Saves the class dump into seperate files :param dict class_dump: a parsed dict of a class dump of an app :param str local_file_path: the file path to save the class dump to :return: nothing Class format: // // // Generated by Scrounger v1.0 // // ClassName // // base properties // instance_properties // base_methods // instance_ methods // protocols """ from scrounger.utils.config import _VERSION header = """ // // // Generated by Scrounger v{} // // {} // """ attribute = """ // {} {} """ for app_class in class_dump: file_name = "{}/{}.h".format(local_file_path, app_class["name"]) with open(file_name, "w") as fp: fp.write(header.format(_VERSION, app_class["name"])) for field_type in app_class: if field_type != "name": fp.write(attribute.format(field_type.replace("_", " "), "\n".join(app_class[field_type]))) def jtool_class_dump_to_dict(output): """ Parses the output of a class dump from jtool to a dictionary :param str ouput: the class dump output to parse :return: a dict with the parsed classes, methods, properties and functions """ parsing_types = { "properties": "base_properties", "instance variable": "instance_properties", "instance methods": "instance_methods", "class methods": "base_methods", } classes = [] working_class = None parsing_type = "" collected_types = [] for line in output.split("\n"): if any(key in line for key in parsing_types): if working_class and collected_types and parsing_type: working_class[parsing_type] = collected_types collected_types = [] parsing_type = "" for key in parsing_types: if key in line: parsing_type = parsing_types[key] elif "Dumping class" in line: working_class = { "name": line.split("(", 1)[-1].strip()[:-1] } elif line.startswith("//"): continue elif "@end" in line: working_class[parsing_type] = collected_types classes += [working_class] working_class = None parsing_type = "" collected_types = [] elif working_class and parsing_type == "base_properties": collected_types += [line.split("//", 1)[0].strip()] elif working_class and parsing_type == "instance_properties": attribute_type = _get_attribute_type(line.split("//", 1)[-1]) parsing_name = line.rsplit(";", 1)[0].rsplit(" ", 1)[-1].strip() collected_types += ["{} {};".format(attribute_type, parsing_name)] elif working_class and (parsing_type == "instance_methods" or \ parsing_type == "base_methods"): method_types = _get_types(line.strip().split("// Protocol ", 1)[-1]) method_name = line.split("/ ", 1)[-1][2:].split(";", 1)[0].strip() full_method_name = _get_method_name(method_name, method_types[1:]) collected_types += ["{} ({}){};".format( "-" if parsing_type == "instance_methods" else "+", method_types[0], full_method_name)] return classes def otool_class_dump_to_dict(output): """ Parses the output of a class dump from otool to a dictionary :param str ouput: the class dump output to parse :return: a dict with the parsed classes, methods, properties and functions """ parsing_types = { "baseProperties": "base_properties", "instanceProperties": "instance_properties", "instanceMethods": "instance_methods", "baseProtocols": "protocols", "baseMethods": "base_methods" } # prepare variables classes = [] working_class = None parsing_type = parsing_name = "" # parse output for line in output.split("\n"): parsing_types_found = [ptype in line for ptype in parsing_types] # start parsing class if working_class == None and "struct class_ro_t" in line: parsing_type = "class" #if working_class != None and "name" in working_class: #classes += [working_class] working_class = {} elif parsing_type == "class" and "name" in line: working_class["name"] = _get_name(line) # starting different class elif working_class != None and not line.startswith(" ")\ and not line.startswith("\t") and not line.startswith("Meta Class"): # check if last class was fully parsed and save it if "name" in working_class: classes += [working_class] # clean helper variables working_class = None parsing_name = parsing_type = "" # parse methods and properties names elif working_class != None and any(parsing_types_found): parsing_type = parsing_types.values()[ parsing_types_found.index(True)] if parsing_type not in working_class: working_class[parsing_type] = [] elif parsing_type in parsing_types.values() and "name" in line: parsing_name = _get_name(line) # parse properties elif parsing_type == "base_properties" and parsing_name\ and "attributes" in line: attribute_type = _get_attribute_type(line) attribute_properties = _get_attribute_properties(line) working_class["base_properties"] += ["@property{} {} {};".format( attribute_properties, attribute_type, parsing_name)] parsing_name = "" elif parsing_type == "instance_properties" and parsing_name\ and "type" in line: attribute_type = _get_attribute_type(line) working_class["instance_properties"] += ["{} {};".format( attribute_type, parsing_name)] parsing_name = "" # parse methods elif parsing_type == "instance_methods" and parsing_name\ and "types" in line: method_types = _get_types(line.strip().split(" ", 2)[-1]) full_method_name = _get_method_name(parsing_name, method_types[1:]) working_class["instance_methods"] += ["+ ({}){};".format( method_types[0], full_method_name)] parsing_name = "" elif parsing_type == "base_methods" and parsing_name\ and "types" in line: method_types = _get_types(line.strip().split(" ", 2)[-1]) full_method_name = _get_method_name(parsing_name, method_types[1:]) working_class["base_methods"] += ["- ({}){};".format( method_types[0], full_method_name)] parsing_name = "" # parse protocols elif parsing_type == "protocols" and parsing_name and "type" in line: protocol_type = _get_attribute_type(line) working_class["protocols"] += ["{} {};".format(protocol_type, parsing_name)] parsing_name = "" # reached the end of the classes elif 'Contents of' in line\ and not "Contents of (__DATA,__objc_classlist) section" in line: break parsing_types_found = [] return classes def _get_name(name_string): """ Parses the name of a method, class, attribute, property from a class dump :param str name_string: the string from a class dump to be parsed :return: the name found on the string """ return name_string.strip().rsplit(" ", 1)[-1].strip() def _get_types(type_string): """ Parses a string a a list of types on the string :param str type_string: the string from a class dump to be parsed :return: a list with types """ known_types = { "v": "void", "f": "float", "s": "short", "S": "short", "I": "unsigned int", "C": "unsigned char", "i": "long long", "q": "long long", "d": "double", "B": "Bool", "c": "Bool", "Q": "Bool", "l": "long", "L": "long", "*": "char * ", "@": "id", "#": "Class", ":": "SEL", "%": "UnkownType" } # replace unkown types type_string = type_string.replace( "@0:", "").replace("@?", "%").replace("^?", "%") # prepare variables types = [] new_type = None new_type_found = 0 # there can be nested new types - just parsing the first # parse string for char in type_string: # found new type if char == "{": new_type_found += 1 if new_type_found == 1: new_type = "" # save new type elif char == "=" and new_type_found: types += ["struct {}".format(new_type)] new_type = None # parsing new type name elif new_type_found > 0 and new_type != None: new_type += char # stop parsing new type elif char == "}": new_type_found -= 1 # check if known type elif char in known_types and new_type_found == 0: types += [known_types[char]] return types def _get_method_name(name_string, types): """ Returns the method name with the correct parsed types for the arguments :param str name_string: a string from a class dump that contains the name of the method without the types :param list types: a list of types for the arguments of the method :return: a str with the method name and types of arguments """ # return the name of the method without arguments if len(types) == 0: return name_string.replace(":", "") # add void types if there are more arguments than types while name_string.count(":") > len(types): types += ["void"] typed_method_name = [] # [:-1] since the last : would generate an empty argument for index, partial_method_name in enumerate(name_string.split(":")[:-1]): # format is [partial method name]:([type])[argument name] typed_method_name += ["{}:({})arg{}".format(partial_method_name, types[index], (index+1))] return " ".join(typed_method_name) def _get_attribute_type(attribute_string): """ Returns the type of an attribute given in a string :param str attribute_string: the string from a class dump containing an attribute :return: a string with the attribute type """ import re # split the whole string by spaces to get the last argument which contains # the type and the properties of the attribute - [0] gets only the type attribute_string = attribute_string.rsplit(" ", 1)[-1].split(",")[0] #line.strip().rsplit(' ', 1)[-1] # unkown symbol - may indicate struct if attribute_string.startswith("T"): attribute_string = attribute_string[1:] # check if pointer if attribute_string.startswith("@\""): # get content between " return "{} *".format(attribute_string.split("\"")[-2]) attribute_type = _get_types(attribute_string) # if attribute type not found default to id if not attribute_type: return "id" return attribute_type[0] def _get_attribute_properties(attribute_string): """ Returns the properties of the attribute from a dumped sting :param str attribute_string: the string from a class dump containing an attribute :return: a string containing the parsed properties of an attribute """ known_attributes = { "N": "nonatomic", "R": "readonly", "C": "copy", "&": "retain" } # split the whole string by spaces to get the last argument which contains # the type and the properties of the attribute - [1:] gets only the # properties attributes = attribute_string.rsplit(" ", 1)[-1].split(",")[1:] fully_named_attributes = ", ".join([ known_attributes[attribute] for attribute in attributes if attribute in known_attributes]) # check if weak attribute if "W" in attributes: return "({}) __weak".format(fully_named_attributes) return "({})".format(fully_named_attributes)
Functions
def application_path(
root_path)
Given a root path try to identify the application's path returning the /path/to/Payload/App.app
:param str root_path: path to start looking from :return: the path to the application or "" if not found
def application_path(root_path): """ Given a root path try to identify the application's path returning the /path/to/Payload/App.app :param str root_path: path to start looking from :return: the path to the application or "" if not found """ if root_path.endswith("/"): root_path = root_path[:-1] if root_path.endswith(".app"): return root_path found_apps = _execute("find {} -name \"*.app\"".format(root_path)) return found_apps.split("\n")[0]
def devices(
)
Find connected iDevices
:return: a list of idevice UDIDs and Names
def devices(): """ Find connected iDevices :return: a list of idevice UDIDs and Names """ @requires_binary("lsusb") @requires_binary("grep") def _connected_devices(): from scrounger.utils.general import remove_multiple_spaces output = _execute("lsusb -v | grep -E \"idVendor|idProduct|iSerial\"") devices = {} # finds apple devices lines = iter(output.split("\n")) for vendor in lines: product, serial = next(lines, ""), next(lines, "") if "apple" in vendor.lower(): serial = serial.strip().rsplit(" ", 1)[-1] devices[serial] = remove_multiple_spaces( product).split(" ", 2)[-1] return devices return _connected_devices()
def entitlements(
local_app_binary)
Returns entitlements of a binary app installed on ios
:param str local_app_binary: the app to check the entitlements from :return: a dict with the entitlements
def entitlements(local_app_binary): """ Returns entitlements of a binary app installed on ios :param str local_app_binary: the app to check the entitlements from :return: a dict with the entitlements """ @requires_binary("ldid") def _entitlements(local_app_binary): # prepare binary local_app_binary = local_app_binary.replace(" ", "\ ") ents_str = _execute("ldid -e {}".format(local_app_binary)) # fix multiple entitlements for multiple archs """ ents = "" for line in ents_str.split("\n"): if not line: break ents += line """ ents = "{}</plist>".format(ents_str.split("</plist>")[0]) return plist_to_dict(ents) return _entitlements(local_app_binary)
def info(
local_application_path)
Retreived information about the application
:param str local_application_path: application's path to get the information from :return: a dict with the information about the application
def info(local_application_path): """ Retreived information about the application :param str local_application_path: application's path to get the information from :return: a dict with the information about the application """ return plist("{}/Info.plist".format(local_application_path))
def jtool_archs(
local_app_binary)
Get available archs from the binary
:param str local_app_binary: the app to get the archs from :return: a list with the available archs
def jtool_archs(local_app_binary): """ Get available archs from the binary :param str local_app_binary: the app to get the archs from :return: a list with the available archs """ import re archs = [] local_app_binary = local_app_binary.replace(" ", "\ ") archs_result = _execute("jtool -v -h {}".format(local_app_binary)) # check for multiple archs arch_no = re.findall(r"\d+\ architecture", archs_result) if len(arch_no) > 0: arch_no = int(arch_no[0].split(" ", 1)[0]) for arch in re.findall(r"arm(v6|v6s|v7|64)", archs_result): archs += ["arm{}".format(arch)] # for some reason jtool doesnt display arm64 if len(archs) < arch_no: archs += ["arm64"] return archs # only 1 arch return ["arm{}".format(arch) for arch in re.findall(r"arm(v6|v6s|v7|64)", archs_result.lower())]
def jtool_class_dump(
local_app_binary)
Dumps classes of an ios application using jtool
:param str local_app_binary: the application binary to dump classes from :return: a str with the output of jtool
def jtool_class_dump(local_app_binary): """ Dumps classes of an ios application using jtool :param str local_app_binary: the application binary to dump classes from :return: a str with the output of jtool """ @requires_binary("jtool") def _jtool_class_dump(local_app_binary): # prepare binary and assume arm64 arch local_app_binary = local_app_binary.replace(" ", "\ ") return _execute("jtool -v -d objc -arch arm64 {}".format( local_app_binary)) return _jtool_class_dump(local_app_binary)
def jtool_class_dump_to_dict(
output)
Parses the output of a class dump from jtool to a dictionary
:param str ouput: the class dump output to parse :return: a dict with the parsed classes, methods, properties and functions
def jtool_class_dump_to_dict(output): """ Parses the output of a class dump from jtool to a dictionary :param str ouput: the class dump output to parse :return: a dict with the parsed classes, methods, properties and functions """ parsing_types = { "properties": "base_properties", "instance variable": "instance_properties", "instance methods": "instance_methods", "class methods": "base_methods", } classes = [] working_class = None parsing_type = "" collected_types = [] for line in output.split("\n"): if any(key in line for key in parsing_types): if working_class and collected_types and parsing_type: working_class[parsing_type] = collected_types collected_types = [] parsing_type = "" for key in parsing_types: if key in line: parsing_type = parsing_types[key] elif "Dumping class" in line: working_class = { "name": line.split("(", 1)[-1].strip()[:-1] } elif line.startswith("//"): continue elif "@end" in line: working_class[parsing_type] = collected_types classes += [working_class] working_class = None parsing_type = "" collected_types = [] elif working_class and parsing_type == "base_properties": collected_types += [line.split("//", 1)[0].strip()] elif working_class and parsing_type == "instance_properties": attribute_type = _get_attribute_type(line.split("//", 1)[-1]) parsing_name = line.rsplit(";", 1)[0].rsplit(" ", 1)[-1].strip() collected_types += ["{} {};".format(attribute_type, parsing_name)] elif working_class and (parsing_type == "instance_methods" or \ parsing_type == "base_methods"): method_types = _get_types(line.strip().split("// Protocol ", 1)[-1]) method_name = line.split("/ ", 1)[-1][2:].split(";", 1)[0].strip() full_method_name = _get_method_name(method_name, method_types[1:]) collected_types += ["{} ({}){};".format( "-" if parsing_type == "instance_methods" else "+", method_types[0], full_method_name)] return classes
def jtool_flags(
local_app_binary)
Returns the compilation flags from an iOS app using jtool
:param str local_app_binary: the path to the app to get the flags from :return: the flags
def jtool_flags(local_app_binary): """ Returns the compilation flags from an iOS app using jtool :param str local_app_binary: the path to the app to get the flags from :return: the flags """ @requires_binary("jtool") def _jtool_flags(local_app_binary): # prepare binary and assume arm64 arch local_app_binary = local_app_binary.replace(" ", "\ ") arch = jtool_archs(local_app_binary)[-1] return _execute("jtool -v -h -arch {} {}".format(arch,local_app_binary)) return _jtool_flags(local_app_binary)
def jtool_symbols(
local_app_binary)
Returns the symbols table from a local iOS app using jtool
:param str local_app_binary: the path to the app to get the symbols from :return: the symbols table
def jtool_symbols(local_app_binary): """ Returns the symbols table from a local iOS app using jtool :param str local_app_binary: the path to the app to get the symbols from :return: the symbols table """ @requires_binary("jtool") def _jtool_symbols(local_app_binary): # prepare binary and assume arm64 arch local_app_binary = local_app_binary.replace(" ", "\ ") arch = jtool_archs(local_app_binary)[-1] return _execute("jtool -S -arch {} {}".format(arch, local_app_binary)) return _jtool_symbols(local_app_binary)
def otool_archs(
local_app_binary)
Get available archs from the binary
:param str local_app_binary: the app to get the archs from :return: a list with the available archs
def otool_archs(local_app_binary): """ Get available archs from the binary :param str local_app_binary: the app to get the archs from :return: a list with the available archs """ import re # get flags flags = otool_flags(local_app_binary) return map(lambda arch: "arm{}".format(arch), re.findall(r"arm[ ]+(v6|v7|v7s|64) ", flags.lower()))
def otool_class_dump(
local_app_binary)
Dumps classes of an ios application using otool
:param str local_app_binary: the application binary to dump classes from :return: a str with the output of otool
def otool_class_dump(local_app_binary): """ Dumps classes of an ios application using otool :param str local_app_binary: the application binary to dump classes from :return: a str with the output of otool """ @requires_binary("otool") def _otool_class_dump(local_app_binary): # prepare binary local_app_binary = local_app_binary.replace(" ", "\ ") return _execute("otool -ov {}".format(local_app_binary)) return _otool_class_dump(local_app_binary)
def otool_class_dump_to_dict(
output)
Parses the output of a class dump from otool to a dictionary
:param str ouput: the class dump output to parse :return: a dict with the parsed classes, methods, properties and functions
def otool_class_dump_to_dict(output): """ Parses the output of a class dump from otool to a dictionary :param str ouput: the class dump output to parse :return: a dict with the parsed classes, methods, properties and functions """ parsing_types = { "baseProperties": "base_properties", "instanceProperties": "instance_properties", "instanceMethods": "instance_methods", "baseProtocols": "protocols", "baseMethods": "base_methods" } # prepare variables classes = [] working_class = None parsing_type = parsing_name = "" # parse output for line in output.split("\n"): parsing_types_found = [ptype in line for ptype in parsing_types] # start parsing class if working_class == None and "struct class_ro_t" in line: parsing_type = "class" #if working_class != None and "name" in working_class: #classes += [working_class] working_class = {} elif parsing_type == "class" and "name" in line: working_class["name"] = _get_name(line) # starting different class elif working_class != None and not line.startswith(" ")\ and not line.startswith("\t") and not line.startswith("Meta Class"): # check if last class was fully parsed and save it if "name" in working_class: classes += [working_class] # clean helper variables working_class = None parsing_name = parsing_type = "" # parse methods and properties names elif working_class != None and any(parsing_types_found): parsing_type = parsing_types.values()[ parsing_types_found.index(True)] if parsing_type not in working_class: working_class[parsing_type] = [] elif parsing_type in parsing_types.values() and "name" in line: parsing_name = _get_name(line) # parse properties elif parsing_type == "base_properties" and parsing_name\ and "attributes" in line: attribute_type = _get_attribute_type(line) attribute_properties = _get_attribute_properties(line) working_class["base_properties"] += ["@property{} {} {};".format( attribute_properties, attribute_type, parsing_name)] parsing_name = "" elif parsing_type == "instance_properties" and parsing_name\ and "type" in line: attribute_type = _get_attribute_type(line) working_class["instance_properties"] += ["{} {};".format( attribute_type, parsing_name)] parsing_name = "" # parse methods elif parsing_type == "instance_methods" and parsing_name\ and "types" in line: method_types = _get_types(line.strip().split(" ", 2)[-1]) full_method_name = _get_method_name(parsing_name, method_types[1:]) working_class["instance_methods"] += ["+ ({}){};".format( method_types[0], full_method_name)] parsing_name = "" elif parsing_type == "base_methods" and parsing_name\ and "types" in line: method_types = _get_types(line.strip().split(" ", 2)[-1]) full_method_name = _get_method_name(parsing_name, method_types[1:]) working_class["base_methods"] += ["- ({}){};".format( method_types[0], full_method_name)] parsing_name = "" # parse protocols elif parsing_type == "protocols" and parsing_name and "type" in line: protocol_type = _get_attribute_type(line) working_class["protocols"] += ["{} {};".format(protocol_type, parsing_name)] parsing_name = "" # reached the end of the classes elif 'Contents of' in line\ and not "Contents of (__DATA,__objc_classlist) section" in line: break parsing_types_found = [] return classes
def otool_flags(
local_app_binary)
Returns the compilation flags from an iOS app using otool
:param str local_app_binary: the path to the app to get the flags from :return: the flags
def otool_flags(local_app_binary): """ Returns the compilation flags from an iOS app using otool :param str local_app_binary: the path to the app to get the flags from :return: the flags """ @requires_binary("otool") def _otool_flags(local_app_binary): # prepare binary local_app_binary = local_app_binary.replace(" ", "\ ") return _execute("otool -hv {}".format(local_app_binary)) return _otool_flags(local_app_binary)
def otool_symbols(
local_app_binary)
Returns the symbols table from a local iOS app using otool
:param str local_app_binary: the path to the app to get the symbols from :return: the symbols table
def otool_symbols(local_app_binary): """ Returns the symbols table from a local iOS app using otool :param str local_app_binary: the path to the app to get the symbols from :return: the symbols table """ @requires_binary("otool") def _otool_symbols(local_app_binary): # prepare binary local_app_binary = local_app_binary.replace(" ", "\ ") return _execute("otool -Iv {}".format(local_app_binary)) return _otool_symbols(local_app_binary)
def plist(
local_file)
Reads and returns a plist file in dict form
:param str local_file: the plist list file to read :return: a dict with the plist content
def plist(local_file): """ Reads and returns a plist file in dict form :param str local_file: the plist list file to read :return: a dict with the plist content """ import biplist return biplist.readPlist(local_file)
def plist_dict_to_xml(
plist, key=None)
Converts a plist dict into an xml string
:param dict plist: the plist to convert :param str key: if the key is set and in the plist it will be the only tag returned :return: an xml string containing the plist
def plist_dict_to_xml(plist, key=None): """ Converts a plist dict into an xml string :param dict plist: the plist to convert :param str key: if the key is set and in the plist it will be the only tag returned :return: an xml string containing the plist """ import plistlib if key and key in plist: plist = plist[key] xml = plistlib.writePlistToString(plist) return '\n'.join(xml.split('\n')[3:-2])
def plist_to_dict(
plist)
Converts a plist file output to a python dictionary
:param str plist: the output of a plist file :return: a dict with the plist contents
def plist_to_dict(plist): """ Converts a plist file output to a python dictionary :param str plist: the output of a plist file :return: a dict with the plist contents """ import biplist return biplist.readPlistFromString(plist)
def save_class_dump(
class_dump, local_file_path)
Saves the class dump into seperate files
:param dict class_dump: a parsed dict of a class dump of an app :param str local_file_path: the file path to save the class dump to :return: nothing
Class format: // // // Generated by Scrounger v1.0 // // ClassName //
// base properties
// instance_properties
// base_methods
// instance_ methods
// protocols
def save_class_dump(class_dump, local_file_path): """ Saves the class dump into seperate files :param dict class_dump: a parsed dict of a class dump of an app :param str local_file_path: the file path to save the class dump to :return: nothing Class format: // // // Generated by Scrounger v1.0 // // ClassName // // base properties // instance_properties // base_methods // instance_ methods // protocols """ from scrounger.utils.config import _VERSION header = """ // // // Generated by Scrounger v{} // // {} // """ attribute = """ // {} {} """ for app_class in class_dump: file_name = "{}/{}.h".format(local_file_path, app_class["name"]) with open(file_name, "w") as fp: fp.write(header.format(_VERSION, app_class["name"])) for field_type in app_class: if field_type != "name": fp.write(attribute.format(field_type.replace("_", " "), "\n".join(app_class[field_type])))
def unzip(
local_ipa_file, target_path)
Unzips an ipa file to target location
:param str local_ipa_file: the file path to the IPA :param str target_path: the target path to unzip the app too :return: nothing
def unzip(local_ipa_file, target_path): """ Unzips an ipa file to target location :param str local_ipa_file: the file path to the IPA :param str target_path: the target path to unzip the app too :return: nothing """ @requires_binary("unzip") def _unzip(local_ipa_file, target_path): #clean path before _execute("rm -rf {}".format(target_path)) _execute("unzip -o {} -d {}".format(local_ipa_file, target_path)) _unzip(local_ipa_file, target_path)


Artwork
Conestoga College 3D logo design - Blender
Dominons 3D design - Blender
Twitch logo - Photoshop
Abstract Wall - Photoshop
Dj logo - Photoshop
Custom layout asset - Illustrator
Custom car wrap design - Photoshop
Island - Blender
Brush effect car wallpaper design - Photoshop
Styled background logo - Photoshop


×
×
OpenCPU API Explorer
API docs
Example Apps
JavaScript Client
PDF manual
Source Code
HTTP request options
Method
GET
POST
OPTIONS
Endpoint
Method and Endpoint are required. Click below to add additional parameters.
Param Name
Param Value
Add parameter
Add file
Ajax request
×
Welcome!
Use this simple page to poke around at the API. Specify HTTP method, URL and parameters, and click on
Ajax Request
. Note that this page requires a browser with HTML5 support.
0


Many online communities present user-contributed responses to items, such as answers to questions and reviews of products.
User-provided helpfulness votes can make useful responses more visible, but voting is a social process that can gain momentum based on the popularity of responses and the polarity of existing votes.
We propose the Chinese Voting Process (CVP) which models the evolution of helpfulness votes as a self-reinforcing process dependent on position and presentation biases.
We evaluate this model on Amazon product reviews and 84 StackExchange forums, measuring the intrinsic quality of individual responses and behavioral coefficients of different communities.
Figure shows a pattern in online communities of Amazon and more than 200 StackExchange communities.
In the figure, we present two behavioral coefficients, 'Trendiess' (x-axis) and 'Conformity' (y-axis), which we claim are two major
factors of bias. Above embedding presents the varying degrees to which the two factors are present in different online communities.
One interesting result is the clustering of similar communities, even though we used no information on textual content.
Another interesting result is how the coordinates align with our intuitive expectation of bias for each community.
Publications:
Conference:
Moontae Lee, Seok Hyun Jin, David Mimno.
"Beyond Exchangeability: The Chinese Voting Process".
Neural Information Processing Systems (NIPS), 2016,
Barcelona, Spain.
Full Oral (Acceptance rate: 46 / 2500 ~ 1.84%)
[PDF]
[arXiv]
Workshop:
Moontae Lee, Seok Hyun Jin, David Mimno.
"The Chinese Voting Process: The Evolution of Online Helpfulness Evaluations in Product Reviews and Question Answers".
In Proceedings of the 12th INFORMS Workshop on Data Mining and Decision Analytics, Houston, Texas.
Selected for Oral Presentations.
[PDF]
There is a large variety of objects and appliances in human environments, such as stoves,
coffee dispensers, juice extractors, and so on. It is challenging for a roboticist to program a
robot for each of these object types and for each of their instantiations.
In this work, we present a novel approach to manipulation planning
based on the idea that many household objects share similarly-operated object parts.
We formulate the manipulation planning as a structured prediction problem
and design a deep learning model that can handle large noise in the manipulation demonstrations
and learns features from three different modalities: point-clouds, language and trajectory.
In order to collect a large number of manipulation demonstrations for different objects,
we developed a new crowd-sourcing platform called Robobarista.
We test our model on our dataset consisting of 116 objects with 249 parts
along with 250 language instructions, for which there are 1225 crowd-sourced
manipulation demonstrations.
We further show that our robot can even manipulate objects it has never
seen before.
Jaeyong Sung, Seok Hyun Jin, Ian Lenz, Ashutosh Saxena.
"Robobarista: Learning to Manipulate Novel Objects via Deep Multimodal Embedding".
Status: Under review for International Journal of Robotics Research (IJRR).
[PDF]
[arXiv]
Conference:
Jaeyong Sung, Seok Hyun Jin, Ashutosh Saxena.
"Robobarista: Object Part-based Transfer of Manipulation Trajectories from Crowd-sourcing in 3D Pointclouds".
In International Symposium on Robotics Research (ISRR), 2015.
[PDF]
[arXiv]
Workshop:
Jaeyong Sung, Seok Hyun Jin, Ashutosh Saxena.
"Robobarista: Object Part-based Transfer of Manipulation Trajectories from Crowd-sourcing in 3D Pointclouds".
In AAAI-RSS Special Workshop on the 50th Anniversary of Shakey at RSS, 2015.
(
Won 50-years of Shakey Blue Sky Ideas Award
)
Others:
Jaeyong Sung, Ian Lenz, Seok Hyun Jin, Ashutosh Saxena.
"Robobarista: Learning to Manipulate Novel Objects via Deep Multimodal Embedding".
In BayLearn Symposium, 2015.
[PDF (extended abstract)]
{% if site.ajaxify_contact_form %}
{% include ajaxify_content_form.html %}
{% endif %}


I am a graduate from the University of California, San Diego. I have a B.S. in Cognitive Science with a specialization in Human Computer Interaction and a minor in Design.
Graduation date: June 2018
When I'm not conducting user interviews or creating prototypes, I love to immerse myself in other worlds by watching shows, playing video games, or going to Disneyland. Even through these casual activities, I am constantly inspired to find new ways of enhancing everyday experiences for users.
Learning Equality is a non profit organization that delivers online education to places without wi-fi. A particular feature is the content curation (CC) server where content curators put together the material that learners will see. As a result of conducting interviews and synthesizing information about them, a pain point sources in not having a search function available. The product of this project is a mockup of an overall search feature in the server.
The personas, experiences maps, and the previous interviews I had with the users also cultivated the path to the final product. With that said, what I learned most from this project is that getting in the mindset of the user through personas, experiences maps, and the previous interviews is the key to funneling my creative thoughts in the right direction.
In order to understand the integral features that search functions provide, it was necessary to compare and contrast existing search functions on both educational and non-educational platforms that contained an ample amount of different types of files. From the 8 comparisons, there were clearly different emphasis on different features, depending on the user journey in the website.
For example, while Google Drive focuses on the real time search experience by providing results and other suggested searchable material as a dropdown menu on the bar itself (figure 1), Curriki (an educational platform) does not have these features but instead focuses on the metadata and context on the results page (figure 2). Both these features were considered and incorporated in the final design.
The most important features that made it into the final design are broken down as follows:
Overall, the competitive analysis helped clarify exactly how a search function can enhance the user experience when interacting with a website.
After a whole quarter of interviewing and understanding the content curator journey through the CC server, these interview results were analyzed and turned into user personas. These personas ranged from expert to novice in regards to exposure to the CC server, honing in on the variety of necessities each of these different levels needed. After analyzing the content curators's backgrounds, motivation & desires, and obstacles to success, it was clear what their respective needs were.
Example of how the personas contributed to the design of the search function:
A novice was having a difficult time understanding exactly what goes in her channel. A way to solve this would be to allow her to explore the fleshed out channels that all users have access to by using the search bar. Instead of having to click through all the different folders, she can simply type in a topic and see what types of materials people have for it, how they use tags, how they utilize the description feature for resources, how they order the folders and resources, etc.
As a result of creating the experience map, it was clear that the most important feature of the search bar is that it provides easy access to exploration of the entire server. Having access to it relieves the tension that new (or existing) content curators may be feeling from being overwhelmed and intimidated by the ample amount of information that the CC server contains.
In order to physically place my ideas about how to design the search function, I created wireframes on paper about potential structures for it.
Afterwards, I moved onto google slides to clearly see how this search function can be integrated into the CC server. Additionally, with the google slides feature of linking slides to each other, I made the prototype clickable to facilitate the experience of what it would be like to use this search function.
After multiple iterations on the powerpoint as a result of feedback from staff around the office, I moved the final design on InVision.
The link to the final prototype can be found here. Some important features of the prototype are the following:
The University of California, San Diego has a shuttle system it provides for free for all its students, but surprisingly, it is not widely used by the entire population. The bus website, which should be alleviating this confusion, lacks clarity. My group of 5 people created a prototype redesign of the UCSD bus website.
My group and I knew that starting with such a broad perspective was better than immediately narrowing down on something small we did not like because that way, the redesign would truly concentrate on an issue the general population had, not a problem just our group had. Additionally, this taught me the power of performing multiple user interviews. Despite the time it may take, it is worth the tradeoff because factual information is more valuable than assumptions and guesses about what users need help with. Starting large and then narrowing down to the source of the issue was a recurring lesson I learned with this project, especially since this was also the main purpose of the Double Diamond Technique we utilized to come up with our final design.
We conducted two sets of interviews in order to narrow down the scope of the problem. The first set of interviews were conducted in order to understand where the problem points were with the shuttle system. After synthesizing the results, we realized that a huge point of tension that we could focus on was the UCSD bus website, which currently looks like this:
After realizing this, we went back out on the field to conduct more user interviews, this time specifically about the website. We asked them to participate in user testing by performing certain tasks on the website and asking them follow up questions about it. Through this, we discovered trends, mistakes, and slips that users made with the website.
In order to gather our thoughts to approach the prototypes, we used the double diamond technique. The technique first dives into all the different problems of the website, then starts narrowing the problems, finds a single problem, explores the different solutions and once again narrows down on realistic solutions for the website. Additionally, in order to settle which solutions were best for the whole team, we decided to do dot voting and the solutions with the most votes made it to the final solution.
We decided to do a sketching session where we each drew out our own preconceptions for the redesign. After this silent session, we came together as a group and critiqued each other’s work while deciding which features we liked best and wanted to put into the final redesign.
We created paper prototypes about what would go into our recreation. We had two iterations: the first one elaborated on the layout of the website while the second iteration focused on clarifying and enhancing the “favorites” feature of the website as well as detailing how users can discover new routes through the map.
We finally moved on to our final redesign, which can be found here, where we made other changes because we realized what looked good on paper did not translate as well on the actual website. A major change we made was that we did not want the map to immediately show on the homepage but to have the user discover it via the arrow on the homepage, which contains the favorite stop times. This as a whole keeps the homepage less cluttered.
As a part of a Human Computer Interaction Design Course, my group of three and I created a mobile web application based on the topic of “Exchange.” We created Tuber, which exchanges information as well as money between college students.
Because I felt very vulnerable being exposed to things I have never experienced, I gained an incredibly important skill that I still use with my present projects: shamelessly asking for help and support. With my team as my immediate sources of help and the TAs a message away, I grew out of my shyness because I had no choice; otherwise I would have been a sitting duck on the project. Although I learned tons of new skills such as basic User Experience principles, UX techniques, and new coding languages, what contributed most to my growth was definitely learning how to reach out.
Target Audience UCSD College Students
Tools Google Analytics, Javascript, Bootstrap, Heroku, GitHub, HTML/CSS, JQuery
Brainstorming and Inspiration Something that most college students experience is struggling in a class, but sometimes there is no time to sit down with a tutor (or even look for a tutor) for each class and each test. An efficient solution for this that UCSD professors use is called Piazza, which is the main inspiration of our app. It is an online forum that allows the exchange of questions and answers between students and professors. Although useful, it still lacks the ability to facilitate extended personal help that resembles an actual tutoring session, so where Piazza falters is the beginning of the inspiration in creating our app.
Storyboarding required us to think about the various types of personas that needed this type of application. These personas are based off of personal experiences as well as conversations we have had with other fellow college students.
Storyboard
Personas
Marie is a 20-year-old undergraduate Cognitive Science student at UCSD. She loves being involved with her organization and has several positions in it. She struggles with the Math 20 series but with such a packed schedule, she rarely has time to attend office hours, let alone somehow find a tutor. She needs a way to find help with doing better in her math As a part of a Human Computer Interaction Design Course, my group of three and I created a mobile web application based on the topic of “Exchange.” We created Tuber, which exchanges information as well as money between college students classes while still being able to be involved with what she loves.
Tim is an 18-year-old undergraduate with a Math major at UCSD. He attends office hours for his writing class, Dimensions of Culture, but still he could use more help more often to score the A+ that he wants in the class.
In order to easily manipulate the beginning framework of the layout of our app, we utilized paper prototypes, which helped us realize where it faltered and easily allowed us to quickly change any features we needed to. This technique helped facilitate the "fail early, fail fast" ideal.
In addition to drawing out the layouts and rough sketches of the screens, we also made "functional" paper prototypes with each of the screens on different papers. It was functional because we used the "Wizard of Oz" technique, which entails a person moving all the appropriate screens/ buttons as a user taps through the different papers. A live representation of this interaction can be seen in the following video:
After reiterations, we moved from paper to powerpoint. Utilizing google presentations allowed us to create interactive wireframes. Moving our vision of the app online helped us all get on the same page about where our app was headed as well as rearrange some screen layouts so that they looked cleaner and more intuitive.
 From our testing we discovered areas where wording was confusing, where formats were not clear enough to be intuitive about what to do on that page, and which buttons were too small to be immediately salient to the user.
A problem we realized we had was that there was really no incentive for users to further use the app because they had no idea whether or not there were tutors around like how Uber shows nearby drivers. In order to incentivize users to use the app right at the start when entering information about looking for a tutor, we want to let them know that there are indeed available tutors around them who could help them. To present this information, we debated between two different designs.
Experiment The original design was Design A but the some users we tested before thought that it was a section they had to act upon (ie. to choose their tutor), but this should not be the case. This is how we were inspired to make Design B, where it is just informative and less confusing in that aspect. So we compared and contrasted the two different designs with google analytics testing, measuring the amount of unnecessary clicks in that area. The users who were confused about that area would mistakenly tap it.
Results
Chi-Squared Calculations
As a result of our testing and chi-squared calculations, we did not find a significant difference between the two different designs (but this could also be due to the fact that we did not have a large enough subject pool). Still, there was a small trend that made us lean more towards keeping Design B. Additionally, Design A was not completely optimized for mobile due to the input forms not scaling well with it.
Essentially, our final application had two main features: the tutor side and the student side.
The final application was on herokuapp, which is unfortunately not an active link any longer. The following are a few screenshots from the live website:
As a part of a human computer interaction design course, I teamed up with three other people to redesign the Kaibigang Pilipin@(KP) website, an organization at UCSD. Unfortunately, the original website is no longer active so there are no comparison pictures.
I am not an expert in HTML/CSS so the fact that this entire project had to be done through this language was daunting. Luckily with the help of the internet and support from peers, it turned out to be a great challenge that really improved my HTML/CSS skills and made me even more proud of my final work. Additionally, working with clients was seemingly challenging at first given their long list of expectations, but in actuality, it helped steer the project productively. It also taught me to communicate with stakeholders and bring in to light the user needs and the importance of that for their overall website goals.
We first met up with the head people in charge of the KP website to get an idea of how they wanted to improve the current site. We had to meet up multiple times to prioritize and reprioritize visions and expectations. After a few meetings with them, we had a solid foundation of what all of us wanted for the end result.
We each did thorough analysis on other organization websites about their strengths and weaknesses. We looked at their branding, functionality, content, site architecture, and design. This gave us insight on what we wanted to include on the new website.
We conducted user interviews on people who would potentially use the site considering they are the ones we are truly designing for. We interviewed three different types of people: KP board members, KP members, and non-KP members. This information helped us create personas as well as scenarios and use cases for those scenarios, which led to further curating the design of the new website.
Main User Needs:
We first gathered around a table and drew our own wireframes. After we made sure everyone was on the same page, we used a collaborative prototyping tool called MarvelApp and were able to make screens on our own computers.
After about 2–3 weeks of coding and creating, we were able to create the final website found here: here. The pages I was most in charge of were: the Homepage, Ourstory, STAR, and Alumni.
Use this area of the page to describe your project. The icon above is part of a free icon set by Flat Icons. On their website, you can download their free set with 16 icons, or you can purchase the entire set with 146 icons for only $12!
The University of California, San Diego has a shuttle system it provides for free for all its students, but surprisingly, it is not widely used by the entire population. The bus website, which should be alleviating this confusion, lacks clarity. My group of 5 people created a prototype redesign of the UCSD bus website.


Add or change a user
You can add a new user or change their role.
(Link opens in new window)
After registering a new user, please remember to assign them to a court using the button below
You can add a user to this court.
Assign user
Confirm Cancel


"I have many meaningful things to say, they just elude me at this time" -Me 2019
Lorum Ipsum Swagum
Best Animals Ever


My name is Regan Dufort who is 28 years old.
I was Born in Malone, NY
I then lived in Selinsgrove, Pennsylvania for 8 years and developed sports as a passion!
When I was 11 I moved to Washington, D.C. where I attended Stafford Senior High School where football became my passion
I then in 2009 graduated and went to college at Appalachian State University to play more football!
Health and Fitness became my passion after graduation, where I trained at a high end fitness club called Equinox
To transition carrers into web development through the greates bootcamp ever via code fellows!


Thank you for helping me raise money for Island View PTA!
Unfortunately the donation form is temporarily offline. Please check back again tomorrow.
Thank you for your understanding and patience, our volunteers are working quickly to bring it back online for you soon.


Sexual dimorphism is a physical difference between males and females of a species.  The degree of size dimorphism varies across multiple populations and species, and is measured through various traits, such as wing span and body mass. Overall, female owls tend to be slightly larger than males. The exact explanation for this development in owls is unknown. However, there are several theories explaining the development of sexual dimorphism in owls.
One theory suggests that selection has led males to be smaller because it allows them to be efficient foragers. The ability to obtain more food is advantageous during breeding season. In some species, female owls stay at their nest with their eggs while it is the responsibility of the male to bring back food to the nest. However, if food is scarce, the male will first feed itself before feeding the female. Small birds, which are agile, are an important source of food for owls. Male Burrowing owls have been observed to have longer wing chords than females, despite being smaller than females. Furthermore, owls have been observed to be roughly the same size as their prey. This has also been observed in other predatory birds. This suggests that owls with smaller bodies and long wing chords have been selected for because of the increased agility and speed that allows them to catch their prey.
Another popular theory suggests that females have not been selected to be smaller like male owls because of their sexual roles. In many species, female owls may not leave the nest. Therefore, females may have a larger mass to allow them to go without starving for a longer period of time. For example, one hypothesized sexual role is that larger females are more capable of dismembering prey and feeding it to their young, hence why female owls are larger than their male counterparts.
A different theory suggests that the size difference between male and females is due to sexual selection: since large females can choose their mate and may violently reject a male's sexual advances, smaller male owls that have the ability to escape unreceptive females are more likely to have been selected.


Introduction
- Distinctive and repetitive invariants across data, objects, processes etc.
- Patterns emerge from data, ontologies, queries etc.
- Majority of ontologies share a small set of modelling or publishing challenges that can be solved using a common strategy or an established best practice
- An ODP should have a motivating requirements, applicability limits, benefits, and shortcomings associated with it
- ODPs are analogous to software design patterns
Examples
- Trajectory Pattern
- Can be used in transportation domain, wildlife monitoring, scientific cruises
- Information Realization Pattern
- Describes relation between an information object (book) and its physical realization (paper copy of the book)
ODP Types
- Several types of ODPs
- Structural ODPs
- Correspondence ODPs
- Content ODPs
- Reasoning ODPs
- Presentation ODPs
- Lexico-Syntactic ODPs
- Available at ODP Repository
Structural ODPs
- Logical ODPs and Architectural ODPs make up the Structural ODPs
- Logical ODPs
- Composition of logical constructs that solve a problem of expressivity
- Eg: Expressing n-ary relation between concepts
- They are further divided into Logical Macros and Transformation patterns
- Logical Macros are shortcuts to recurrent intuitive logical expressions
- Transformation patterns translate a logical expression from one language to the other
Structural ODPs
- Architectural ODPs
- They have an affect on the overall shape of the ontology
- They aim to constrain how the ontology should look like
- They are chosen if there are specific needs such as any computational complexity constraints
Reasoning ODPs
- They are applications of Logical ODPs to obtain certain reasoning results
- Eg: Classification (all superclasses for each class in the ontology)
- They provide hints to the reasoner as to what kind of reasoning has to be performed in order to answer queries
Correspondence ODPs
- Correspondence ODPs are divided into Reengineering ODPs and Mapping (or Alignment) ODPs
- Reengineering ODPs
- They are design solutions that transform a conceptual model into an ontological model
- The source model can be a non-ontological model such as a thesaurus, UML model etc.
- Schema reengineering patterns and Refactoring patterns are sub categories of Reengineering ODPs
- Schema reengineering patterns are rules to transform a non-OWL ontology to an OWL ontology
Correspondence ODPs
- Refactoring patterns transform (refactor) models in the same form. For example, from one OWL 2 DL ontology to another
- Eg: An ontology defines an object property to represent preparing coffee between agent and coffee
- Time of coffee preparation and the tool used should also be added
- An n-ary Logical ODP needs to be used because the property preparing coffee needs to be associated with agent, coffee, time, tool
- The n-ary Logical ODP and the mechanism to replace the existing object property together form the Refactoring ODP
Correspondence ODPs
- Mapping patterns provide design solutions to relate two ontologies without changing the logical types of the ontology entities
- They provide semantic relations between mappable elements in the ontologies
- There are 3 basic semantic relations used for mapping: equivalence, containment, and overlap
- The negative counterparts are also included such as not equivalent, not contained, and no overlap or disjoint
Presentation ODPs
- They deal with usability and readability of ontologies from a user perspective
- They are meant to be good practices that support reuse of ontologies
- Naming ODPs and Annotation ODPs are types of Presentation ODPs
- Naming ODPs are naming conventions for files, namespaces, and ontological entities (class, property, instace)
- Annotation ODPs provide annotation properties such as label (description of an entity, synonyms etc.), seeAlso, versionInfo etc.
Lexico-Syntactic ODPs
- They are linguistic structures or schemas that consist of words following specific order
- They can be used to associate natural language sentences with other ODPs such as Logical and Content ODPs
Content ODPs (CPs)
- Small ontologies that mediate between use cases (problem types) and design solutions
- They are the building blocks to create ontologies
- An ontology can be built by composing different CPs with appropriate dependencies between them and by expanding the CPs as needed
ODP Description
- An ODP can be described using the following fields
- Name
- Intent
- Competency questions
- Alternate names
- Scenarios: Examples of requirements in natural language that can be modelled using this pattern
- Diagram: UML diagram representing the pattern
- Elements: list classes and relations in the pattern
- Consequences: description of benefits and trade-offs
- Known uses: examples of realistic ontologies where the pattern can be used
- Extracted/Reengineered from: reference ontology or conceptual schema from which the pattern has been extracted
- Related patterns: other patterns that are either a specialization, generalization, composition, or component of this pattern. Also lists patterns that are generally used along with the described pattern
- Building block: a reference implementation (URI or owl file)
AgentRole ODP
- Name: Agent Role
- Intent: To represent agents and the role they play
- Competency questions
- what is the role that is played by an agent?
- which agent plays this role?
- Consequences: allows designers to make assertions on roles played by agents without involving the agents that play those roles, and vice versa. It does not allow to express temporariness of roles
- Scenarios: She greeted us all in her various roles of mother, friend, and daughter
Information Realization ODP
- Name: Information Realization
- Description: It represents the relations between information objects like
poems, songs, formulas, etc., and their physical realizations like printed books, registered tracks, physical files, etc
- Intent: To represent information objects and their physical realization.
- Competency questions
- what are the physical realizations of this information object?
- what information objects are realized by this physical object?
- Consequences: This pattern allows to distinguish information objects from their concrete realizations
- Scenarios: The book of the "Divina Commedia"


MPI distinguishes ordinary random access files from sequential stream files, such as pipes and tape files. Sequential stream files must be opened with the MPI_MODE_SEQUENTIAL flag set in the amode. For these files, the only permitted data access operations are shared file pointer reads and writes. Filetypes and etypes with holes are erroneous. In addition, the notion of file pointer is not meaningful; therefore, calls to MPI_FILE_SEEK_SHARED and MPI_FILE_GET_POSITION_SHARED are erroneous, and the pointer update rules specified for the data access routines do not apply. The amount of data accessed by a data access operation will be the amount requested unless the end of file is reached or an error is raised.
Rationale.
This implies that reading on a pipe will always wait until the
requested amount of data is available or until the process
writing to the pipe has issued an end of file.
( End of rationale.)
Finally,
for some sequential files,
such as those corresponding to magnetic tapes or streaming network connections,
writes to the file may be destructive.
In other words, a write may act as a truncate
(a MPI_FILE_SET_SIZE with size set to the current position)
followed by the write.


Calls all listeners registered in the event.
Name of the event.
Calls all listeners registered in the event.
Name of the event.
Data to send in the event.
Checks if the emitter has registerd event.
Name of the event.
Registers the listener of the event.
Name of the event.
Listener to execute when the event is called.
Registers the listener of the event.
Name of the event.
Listener to execute when the event is called.
Clears all listeners on the event.
Name of the event.
Clears all registered listeners.
Emits the socket event. The response can be handled in the on
method.
Name of the event.
Emits the socket event. The response can be handled in the on
method.
Name of the event.
Socket event key.
Emits the socket event. The response can be handled in the on
method.
Type of parameters.
Name of the event.
Socket event key.
Event parameters.
Emits the socket event. The response can be handled in the on
method.
Type of parameters.
Name of the event.
Socket event key.
Event parameters.
Function called in the progress tick.
Calls the socket event.
Type of response.
Name of the event.
Calls the socket event.
Type of parameters.
Type of response.
Name of the event.
Event parameters.
Calls the socket event.
Type of parameters.
Type of response.
Name of the event.
Event parameters.
Timeout of the event.
Calls the socket event.
Type of parameters.
Type of response.
Name of the event.
Event parameters.
Timeout of the event.
Function called in the progress tick.
Registers socket event listener. This method should be called in componentDidMount
.
Name of the event.
Callback for the event.
Removes the listener of the event.
Name of the event.
Removes the listener of the event.
Name of the event.
Generated using TypeDoc
Decorator for casting response with defined types.
class User extends SocketRequest { @SocketRequest.castResponse({ id: Type.integer, name: Type.string, }) get() { return this.execute('user.get'); } }