I’m sure there is not many of you but I had to tell someone. As of the last few days I’ve really felt the need to get involved in something that is really what I am all about. A new baby if you will, a commercial enterprise but one I own. I’ve been working full-time on Laravel projects and I want to improve my skills to really get better at it. Its a great framework after using raw PHP and template engines like handlebars.
During this time I came to the realisation that I wasn’t totally stoked with the existing flashcard companies out there and I think now more than ever I really have the skills to get something like this off the ground, hopefully this is the first project of many!
Flashcard Club is different,
I really want a modern material feel to the website. I’m not interested in something worse than what there already is out there, I want to really help people.
I want to really build a solid brand that people want to use. Flashcard Club should be a place to really get some work done and cram for that final test and study in a safe space.
I really want to provide a platform for students to get some work done. A lot of the competition has low quality submissions. I really want people to have an effective space to learn.
I want to publicise what I’m up to, and this blog will help with that. A real leading learner approach. From conception to reality.
Although this will have options to buy products, long term I only want this project as a sort of demo of my capabilities. I want to move on to better ideas ASAP but you have to start somewhere.
This is my first “premium domain” project so consider that an invested interest in this project.
Have a look and see how I’m getting on. At the time of writing cloud flare gives out error 526 so I hope to be past that by the time this goes up a month from now.
I aim to make both a website and mobile app, however the majority of the features will be made through the app, the functionality and backend will be possible through the online version as well.
I think my target audience is 99% students so a strong app presence is a must I feel. The website will be a strong start but is just one part of the experience.
I thought I’d share pictures I took when I took apart a 250GB dead hard drive.
Rest in pieces my WD2500AAKX
I got this hard drive as part of a Dell Optiplex 780 and used it as a server for my internal network. It worked great until it wouldn’t boot. I checked on it and sure enough, it was stuck in ubuntu server boot recovery. I tried to recover it but I think I did more damage than good. I decided to move to a Windows computer and tried to recover the data with Recuva which didn’t do anything because it couldn’t pick up the disk, so then I moved to TestDisk which was able to see the drive and partitions but never got past profiling the disk. So then I decided to take it apart.
The hard drive in the Dell Optiplex 780
First I unscrewed all the screws, there is another screw holding the read/write head under the label.
After that I took it apart a little more, it has one platter internally and one big old magnet which I kept.
Well, I’ve let the magic smoke out now.
Interestingly there seems to be a metal piece on the bottom and side of the hard drive which I think is for easy destruction. CrystalDiskInfo said it had 29202 hours on it and 2875 power ons, nearly exactly the same as my ST2000DM001-1CH164 T2B hard drive. The smart data also had warnings for its Reallocated Sectors Count.
When a problem or solution requiring software is conceived it is essential that the software project is properly conveyed to the software house, agency or project staff creating the software. When constructing the document there are defined standards that the SRS may be structured to follow, such as IEEE Std 830-1998 which has been superseded by IEEE Std 29148-2011.
The document may also be written by the customer should the client choose to do so as it may provide more control of the specifications required in the project. Simply a Software Requirements Specification (SRS) could be titled ;
This is what the customer wants the software to do.
Introduction
The introduction should indicate the expected behaviors of the software as clearly as possible detailing the processes, activities, interfaces, and tasks required by the software. The introduction can be muddied if the software is not already clearly conceptualized or thought out or is to be built onto existing software if the requirements are not understood by all parties. It may also be necessary to indicate the expected life cycle, phase-out period and maintenance required to maintain the performance and usability of the software. Users may also be considered.
Purpose
An SRS document may state the purpose of the software which could be considered an ultimate end-goal of the resulting project and consider the project a failure if not met. It should conclude with affirming that this document specifies how the software should be designed, developed, tested and implemented where applicable. If the purpose is to improve the speed of current business processes then make it appear in the purpose section, if the purpose is to improve the usability of the current software used by staff then include it in the purpose section as well. If the software is also supposed to do something not included in the purpose or easily justified by this section, then it can be hard to justify why such a feature should exist in the project.
Scope
The scope of the document is to provide a description of what the document specification includes, such as use cases and requirements. Some of the program may be in multiple documents so the scope is necessary to reduce overlap between projects.
System Overview
System Overview provides a description of the context, function and requirements of the software project.
References
References should indicate if the software is somewhat pre-existing, any references made in the document and references to appendixes should also be included too.
Overall Description
The overall description is the second section of the SRS document.
Product Perspective
A product perspective is a detailed outlook of what the program should appear like to the users of the system, some software projects may be completely transparent to users, if so then the product perspective should outline the interfacing between other software components that make it so.
The overall description should not be vague, it should provide justification as to why the functions of the program are required.
The overall description should detail crucial cornerstones of the program and interfaces that exist with the hardware or software.
Some of the programs may be pre-existing which will require the project interface detailed and easily readable to be understood.
The Description should have six sections,
System Interfaces which the user may interact with the system or the system may interact with other systems.
User Interfaces which the users may interact with which may include the frequency of their usage and the intuitiveness of the design.
Hardware. Including the frequency of use of the hardware, considerations to the longevity of the hardware and ability to update or dispose of the hardware.
Software. Including external interfaces, naming conventions.
Communication and Telecom both in interfaces software to software and to the user.
Memory. Including minimum requirements.
Operations and processes that the program may perform real-time or batch, transaction or otherwise.
Adaptations and the ability to configure the system. For open source or high-security systems, this section may be larger than private or closed source software due to the need to ensure that it is secure or can be maintained or made depreciated quickly.
Design Constraints
What are the limitations of the software?
What might the software fail to perform at?
What are the limitations of the programming language if selected?
How might this delay the project if risks arise?
What are the limitations of the users’ ability?
What training will need to take place in order to use the software effectively?
What does the software not do?
What happens if a user does not use the software as intended?
In most aspects of software engineering, there are simply parts of human nature and failure modes or edge cases that simply cannot always be mitigated, in such scenarios it is important to outline what steps your software has taken to make these issues not slow the productivity of the software and ensure that the system runs as intended part of this may be detailed in test cases written in the appropriate section.
Product Functions
Product Functions should as best as possible describe the function of the program and how the modules of the program if any will work together with the interfaces of the system to produce the software’s desired functions.
The aim of the section is to break down the large characteristics of the program into more readable and manageable sections that can be delegated out to a team or read to an individual clearly without much overlap to avoid confusing what the program is designed to accomplish and what each function does.
The functions should be organized and listed so that they may be read for the first time and understood effectively.
The section may include graphical sections or UML detailing how the program may operate.
The validity of the input.
Sequence diagrams or how the program may pass data between functions.
How the program accounts for abnormality.
Common input examples may be a good way of explaining the function to the reader and providing a sample of what the programmer should accomplish on each function.
Sequencing.
User Characteristics
When a user may use the system either from time to time (i.e. infrequently), once or many many times it is important to detail this information in the user characteristics section and account for this in the software, if the methods used to do something are contrived or confusing it could lead to increased mistakes or data mismanagement further down the line and increase the need for normalization or reconciliation of information.
User Characteristics should detail the factors that affect each user and provide use cases for each user, it may also be ideal to detail overlapping functions that each user may use and diagram where appropriate.
It also may be applicable to detail why each user may need a function of the program.
Specific Requirements
The specific requirements should detail all of the requirements of the clients, the user and the software itself. It should provide suitable detail to enable the software to be written clearly and tested effectively. It should be stated for each requirement which user the requirement is for and if applicable that the test case corresponding to the requirement should be satisfied through cross-referencing other parts of the document.
The requirements should be clearly stated to prevent later mistakes or edge cases, poorly written requirements or poorly designed functions may cause the program to be unstable or possibly unsuitable for use. Proper error handling should be given to most aspects of the programs requirement and how it operates to meet the requirement.
Vagueness or Failings in test cases may allow for requirements to be deliberately misinterpreted, such as “The program must be fast and easy to use” may be considered easy to use for the programmer or tester, and therefore a suitable statement that the requirement is met, but not for the user who may not understand the inner workings of the software and therefore lack the knowledge to use the software effectively as much as the programmer testing the requirement, it may be a good idea to allow the users to try the functions using agile development and adapting the program accordingly.
The final part of the document should include the appendices and the index.
Some things are better if you do them yourself. I mainly did this project to keep a running ledger of the changes that I would need to keep track of the account balance data.
GnuCash is great, but when I export my accounts data the CSV file isn’t easily translated with power-query automatically. I decided that because I need to keep track of my transactions, this problem was best suited with a little program to calculate my net inflows and outflows using a python program, I also decided halfway through the project that I wanted to hook it up to my graphing backend, a silly idea – but a fun one to see my spends go up and down. I decided that I’d publish it here so that in the future I would find it a lot easier.
Traditionally if you wanted to export GnuCash data from CSV to PowerBi, you’d be better off using their inbuilt power query, however, I wanted to implement a ledger system, something that I don’t think can be accomplished directly in PowerBi without some scripting, and in the future I want to be able to change platforms if I need to because I no longer have a licence for PowerBi or want to use something else like excel or free equivalents like Google Sheets. I reckon that if done properly Google Scripts could make everything run automagically from an upload, but I don’t have my reports ready yet for that to happen.
# Extracted from here https://github.com/aidancrane/GnuCash-CSV2CSV-for-PowerBi/blob/master/convert_to_powerBI.py
import csv
from re import sub
from decimal import Decimal
import time
# If we only want the transactions values, set this to true and they will print to console, they do not save to accounts_out.csv!
numbersOnly = False
# Anyone thats not me will want this to be false, this is used to show the transaction data on a live graph I use for scratching around with.
smoothieChartEmulation = False
sessionCookie = "39494goodluckguessingthispartlololol213232expiresanyway"
# Leave this here so that Notepad++ and Atom auto-suggest it.
# Date,Account Name,Number,Description,Notes,Memo,Category,Type,Action,Reconcile,To With Sym,From With Sym,To Num.,From Num.,To Rate/Price,From Rate/Price
if (smoothieChartEmulation):
import requests
# Negative Numbers are bracketed when exported from GNUCash so we need to fix that for the float data type.
def convert_if_negative(number):
returnNumber = str(number)
if ("," in returnNumber):
if ("(" in returnNumber):
returnNumber = returnNumber[1:]
returnNumber = returnNumber[:-1]
returnNumber = returnNumber.replace(",", "")
returnNumber = 0 - round(float(returnNumber), 2)
returnNumber = str(returnNumber).replace(",", "")
if ("(" in returnNumber):
returnNumber = Decimal(sub(r'[^\d.]', '', returnNumber))
return (0 - round(float(returnNumber), 2))
return returnNumber
# open accounts.cvs, our exported file.
with open("accounts.csv", "r") as csvIn:
reader = csv.DictReader(csvIn)
entries = []
runningTotal = float(0)
# Save
for row in reader:
if (row["Account Name"] == ""):
pass
else:
runningTotal = runningTotal + float(convert_if_negative(row["To Num."]))
if (numbersOnly):
print(str(round(runningTotal, 2)))
else:
if (smoothieChartEmulation):
payload = {'random_graph': runningTotal}
r = requests.get('https://dash.infinityflame.co.uk/dash/flex.php', params=payload, cookies={'PHPSESSID': sessionCookie})
print(str(convert_if_negative(row["To Num."])) + " Description: "+ row["Description"] + " Account Balance: " + str(round(runningTotal, 2)))
entries.append([row["Date"],row["Description"],row["Category"],str(convert_if_negative(row["To Num."])),str(round(runningTotal, 2))])
# Save what we care about to our new csv for power BI
with open('accounts_out.csv', mode='w', newline='') as csvOut:
titles = ["Date","Description","Destination","Transaction","Account Balance"]
writer = csv.writer(csvOut, delimiter=',', quotechar='"', quoting=csv.QUOTE_MINIMAL)
writer.writerow(titles)
for transaction in entries:
writer.writerow(transaction)
I used python because it’s quick to debug in Atom and I know it well. The way this snippet is used is to export an account from GnuCash, then use this program to output the final CSV to be taken in by PowerBi, I’ve chained these steps together. The final result is stored in accounts_out.csv.
When a project is at its initial planning stages, it is important that the communication between the customer and the IT system’s creator is maintained to ensure that the project is what the customer wants and needs, that the project meets the customer’s requirements and at the same time a list of requirements is drawn up for the customer to confirm, In doing so it ensures that the customer and client have a consistent idea of what the project will do/how it will function. In doing so, errors are less likely to snowball and problems are identified before they are greater than an idea.
Having an open dialogue during development also allows the customer and IT member to have a good understanding of the requirements of the user and what the user is not interested in, this is especially important for systems where the customer will not be the main user for the system, otherwise problems that the customer did not identify may crop up at later stages, which could be costly and time consuming to rectify in non-common IT systems (unlike common IT systems, where a fix may be easier).
Some projects are started and never completed because many projects do not have realistic deadlines, fail to identify the needs of both the customer and the user. fail to identify the needs of the client, are too expensive or are beyond the ability of the person or team making the project happen.
Why effective ICT teamwork is essential to the development of a successful project.
Effective teamwork ensures that every IT member works to their strengths and that they all have a clear idea of what is expected of them and what they need to do next, what others are doing and what is the end result, this ensures that the project is consistent for the end user and customer and works effectively. Failing these crucial steps may mean that some aspects may need to be repeated, the project may not be completed on time or the overall effectiveness of the project is not as good as it could have been. Developing a project also requires following and leaving rigorous documentation for future development of a solution.
Factors that influence the success of an IT development go beyond catering for the end user.
Two factors that are relatively important when developing a project are ‘effective focus of individuals resources and skills’ and ‘effective time scaling and delegation of tasks’.
Effective Focus of Individuals resources and skills ensures that a network manager is not programming the frontend of an application, although he may be able to ‘give a good go of it’ he or she will not be as good as the front-end developer, especially so if the developer has had consistent immersion with the topic.
Effective time scaling and Delegation of tasks ensures that complex problems are not given too little time to work them out, some problems may also require a long time to work out, so need ample time, additionally if a project, like designing a website takes too long. Then other tasks toward the end of a development may not be completed.
Failing to identify the needs of a client may mean that a project is incorrectly understood and could features are mis-implemented or do need meet one of the clients requirements. This could result in numerous users having to resort to time-intensive ways of working around this task or not using the solution. Additionally systems that are not implemented without proper documentation can delay fixing problems.Some problems may also be that developers did not account for backing up the system, so when a project has a failed implementation or data is not backed up when upgrading a system, the data could be deleted due to poor redundancy steps.
One of the great things about the Raspberry Pi is the community that works to create really great projects. I have setup a Raspberry Pi B looking out my windows. It faces the front door so can see anyone coming down the street and toward the door. I had a couple cheap $2 webcams lying around so I set them up looking out the windows. The total cost of the entire setup is about $10, minus the cost of the Pi itself, I also think that the Pi is a little underpowered for the task as occasionally the thing will stop working after several weeks, the camera still records the video, but the web-interface has to be reloaded in order to get the thing working again.
Overall, I’d say that this project was ineffective for its purpose because unfortunately, the cameras would not record movement accurately enough, and sometimes would record several hours of minimal movement. An IP camera would likely be more cost-effective and better suited for the task, the Pi I used was simply underpowered to monitor two webcams and crashed after about 2 weeks of working continuously. Viewing the files showed that although it captured movement and video, some were corrupt, glitch or only captured about 3 usable frames. It did, however, show a good live view of what was going on outside the house, with about a 4-second delay.
Overall I would say that a Raspberry Pi as a webcam security camera on the cheap is not a good idea, the main contributing factor being that it was not able to keep the program running and often would save garbage to the SD card. If I were to do this again I would not use two for definite as it simply did not work effectively enough to actually increase security, It would often record trees moving for hours and sometimes one camera would freeze up entirely.
It is currently well known that bukkit has been given a dmca request by Wesley Wolfie, but now that that has happened, we now need to rebuild!
So here is whats happening, the folks over from bukkit are now working on a new modding api, called sponge! currently ‘Sponge will start with Minecraft 1.8, with Vanilla Client Support on Forge.’
Old plugins that were written on bukkit will most likely have to be removed, unless someone finds a way to make them compatible with sponge.
Here is a large extract of what they plan to do.
Our ultimate goal is to create a modding API that is easy to use for owners of small servers for friends and family, owners of large servers, and everyone in between. In addition, we also plan to permit client modding.
Sponge mods should work across several different Minecraft versions without needing an update from the developer, which means that you don’t have to worry about all your mods breaking between each new major release of Minecraft (1.6, 1.7, 1.8, etc.).
Sponge will support official interoperability with Forge so you can use both Sponge mods and Forge mods together. We are working directly with the Forge team.
While Sponge will not be directly supporting Bukkit, community projects have been started that aim to provide complete support for existing Bukkit plugins on top of Sponge
