With large applications you’ll typically find yourself breaking your SCSS files into logical groups,
typically centered around functional components. This is clean and efficient, but you lose intellisense
when you do… until now.
To accomplish this, I have started support for the reference tag in a triple slash (///) comment.
An example of this would be
/// <referencepath="variables"/>
To get intellisense for multiple files, just add multiple references
The reference tag works the same as a @import statement, and it can serve
as documentation for what files the current file you are working on depends on.
If you have any other ideas for what you would like to see supported in SassyStudio, please feel free
to submit a feature request on GitHub
In my recent work in SassyStudio to support the
SCSS language I have hit a few hurdles. While I don't have any
problems with the SCSS specification, I think it's worth delving into some tooling hurdles
that I've encountered due to the way SCSS works.
Back To Basics - CSS
First, lets disect a very basic CSS rule set
ulli:hover{color:red;}
Here we have a few components.
ul and li:hover are the "selectors" for this rule.
:hover is a pseudo-selector for the li element that only applies when the element is being hovered over
color:red is setting the color property of the li element's foreground text to red
Pretty simple. The CSS syntax is pretty flat compared to SCSS which adds nesting, so it means that
the selectors will always be at the root of the document and then the rule body will have properties.
It is also worth noting that CSS does not require there to be any whitespace between the colon and the
property value.
Now lets look at an equivalent SCSS rule set
ul{li:hover{color:red;}}
Since SCSS allows us to have nested selectors, we bump into our first problem: pseudo-selectors.
Let's say you have typed out your ul rule set and begin typing li and then hit the colon.
Currently, we are in an ambiguous context: do we have an li element that we would like to show
code completion for pseudo-selectors or do we have a li property?
There's a few ways to resolve this, but they are all brittle: we could try to see if we
have a valid property name, but that requires us to keep an up-to-date schema, including browser
specific properties, which is ideal, but tough. Furthermore, we could have non-text property names and
selector components like #{$some-variable} which would then require us to evaluate the variable,
which could be expensive.
Another way we could address this problem is look at the element and see if there is a pseudo-selector for it.
Unfortunately this won't work because most pseudo-elements apply to all elements.
The most logical way to address this problem (although still not useful in the code completion context)
would be to look for the opening curly brace to determine if something is a selector or not. Unfortunately for us, SCSS supports
nested properties
which means that the following is a completely valid property, not a selector.
Granted in that example there is a space after the colon, but the example doesn't matter as much
as the concept. There's no real definitive way to know definitively tell between a property and
selector when there is only one value, and thus, the only safe way to handle this scenario from tooling is by not providing
completion for pseudo-selectors, only properties.
This is still not ideal, but it's better than the alternative, which would be that anytime you entered the property
value context by typing a colon, you would get a list of pseudo-selectors, pseudo-classes, and pseudo-functions.
Since you are likely to be providing more properties than selectors in a document, I chose to err on the side of assuming
something is a property.
Reflecting back
When it all comes down to it, the main problem here is that the SCSS language (which is a superset of CSS3)
introduces some ambiguities that were not present in CSS3. While they are fairly easy to work around at a
document level, they aren't as easy to work around in an interactive environment.
How would I solve this? Unfortunately, I don't have any great ideas yet.
Ultimately, if there was an operator for nested selector like the parent reference operator, this wouldn't
be a problem. We would have an easy way to tell the context we were in and it would make parsing a lot simipler.
On the other hand, it's not really necessary and would likely get annoying. Ultimately the problem arises
only when you are in the process of writing your document; everything is simpler when dealing with the document
as a whole. Unfortunately, that's almost the entire process from the tooling aspect.
Since Apple announced that the new iPhone would have a fingerprint reader there has been a lot of concerns about privacy.
I'll try to explain the fingerprint technology that Apple is using as I understand it and attempt to address some of the
concerns I have heard being raised.
What I present here is based on my experience as a developer working with the Authentec SDK (whom Apple acquired a little while ago)
but I am by no means an expert. My experience is limited to the Authentec SDK and the Zvetco fingerprint sensor.
A high level look at what is happening
When you place your fingerprint on the sensor, it doesn't "scan" your fingerprint like your typical scanner.
The sensor maps the electrical conductivity of the fingerprint and generates a model of your fingerprint.
This can then be converted into an image which would resemble your fingerprint, but it's important to understand
that it's done via conductivity because a paper is not electrically conductive and thus you could not trick the sensor
with a picture of a fingerprint.
Once the fingerprint has been mapped by the sensor the next step is to generate the fingerprint template.
The template is basically just enough information about your fingerprint to match it again, but it is not an image of the fingerprint.
This is what Apple will store, and I do not believe that you would be able to recreate the fingerprint image from
the template.
The fingerprint image
As I stated above, the map of the fingerprint can be visualized in a what that very closely resembles your fingerprint because it
is almost like taking a picture of your finger. The lifetime of this map, however, is likely very short.
Typically once the fingerprint has been scanned the sensor notifies the operating system that a new map is ready and the operating system
would then pass that on to the authentication system which will request the fingerprint map data from the sensor.
Once the sensor provides the data to the requestor, it could immediately discard the information or after a certain period of time.
I cannot tell you for certain what the iPhone sensor does, but I would guess that if it doesn't discard immediately, it does so within a short period
of time.
The template
When it comes to the actual information the template actually stores, I'm a complete novice. I'm going to speculate on what it likely stores,
but I would definitely not consider it to be correct, but likely something like that.
The template represents enough information to repeatedly match the fingerprint, but it is not a monolithic piece of data.
Typically, you will generate the template by "enrolling" the fingerprint which consists of three to five scans of the fingerprint.
Once the enrollment is done, you can now match subsequent fingerprint scans to the template. Typically, you would update the template with subsequent
scans as well, improving the accuracy of the matching over time.
I have seen other articles which
state that perhaps Apple is hashing the template, which would make the template indecipherable, but it would also make the accuracy very low and
would not allow the template to be updateable, so I do not believe that is what Apple is doing. At the same time, I do not believe that you
can get much information about the fingerprint from the template.
So what is in the template? Like I said, I really don't know. If I were to guess, I would say that they first detect some of the more
prominent fingerprint features (such as swirls, loops, etc), and then take some measurements between those features. The algorithm
should pick the prominent features each time, and thus is just needs to validate that the measurements are within tolerances and then
it would be considered a match.
If you are curious as to what data the template stores, you can download my fingerprint template
and play around with the data and see what information you can extract from it. This template was generated using the Authentec SDK about 3-4 years ago.
I would be genuinely interested in what you can decipher from the template.
Conclusion
Ultimately, I don't think there are very many privacy concerns here. I don't believe you can reverse engineer the template back into
something that resembles a fingerprint, which is why I feel comfortable posting my template onto the internet. Apple claims that the
template is not transfered anywhere, so the privacy concern should be even less.
Companies come and go and content hosts are no different.
Unfortunately, they can go fairly suddenly and if you aren't careful your content could go along with it.
There are some very simple steps that you can take to insulate yourself from these unforeseen events.
Use your own domain name
This is hands down the simplest and cheapest safeguard your online presence.
Unless you are in dire needs of a four-letter domain name, you can acquire a domain name for around $4 - $30 a year,
depending on the the TLD you choose. You are now no longer tied to your host's domain.
Own your content
This may sound stupid, but it is overlooked often yet can be achieved very simply by just ensuring that you either
are in possession of all of your content or whoever is hosting your content provides you with a method to export the content.
What you don't want is to find yourself in a situation where you need to figure out a way to get your content off of the host's system
quickly before it disappears. I wouldn't recommend relying on Archive.org as a backup method.
Use FeedBurner (or similar service) for syndication
When you use a service like FeedBurner to host your RSS
feeds, you can change the location of the feed whenever necessary without requiring all your subscribers to update their subscriptions.
If you don't have your own domain, using FeedBurner would allow you to switch hosting providers without affecting subscribers to your RSS feed.
While some have cried out saying that you shouldn't use FeedBurner,
I believe that the benefits that you can gain from using FeedBurner to serve your RSS feed far outweigh the consequences, which are easily mitigated.
If you do own your own domain name, you can leverage the benefits of FeedBurner while insulating yourself further from the impact of FeedBurner disappearing.
To do this, you can use the MyBrand feature that FeedBurner offers which allows you to
take a subdomain like feeds.darrenkopp.com and point it to the FeedBurner servers.
Now, if the day comes that FeedBurner goes offline, you can just change the CNAME
from the FeedBurner servers to back to your domain and host and serve your RSS feed from there and no one will ever that anything changed.
If you are extremely concerned about Google taking the axe to FeedBurner, then I would suggest that you look into some alternatives like
FeedBlitz or FeedPress.
Use analytics
Analytics may seem like an odd suggestion here since you likely won't be in complete control of the data, but it is very important to your presence in general.
The best way to stay in control is to understand what your online presence actually means to those who are visiting you.
The primary reason I left WordPress was that I found myself needing more information than their analytics provided.
By possessing more information about who is coming to visit your site, where they are coming from, and what they are doing while there, you are able to make the experience more enriching.
Countless times I have seen an author or site owner engaged in the discussion on Reddit or Hacker News after noticing a large spike of traffic to something on their website.
Without being able to find out where those users were coming from, they may not have been able to add to that conversation or learn new insights from what others were saying.
There are lots of great analytics providers out there for free or paid.
Do your research and pick someone who offers what you want to know.
Some of the larger providers include Google Analytics,
StatCounter,
Gaug.es, and many more.
Many content providers also provide stats that may serve all of your needs.
It's worth mentioning Google Webmaster Tools
here since you can get some very useful statistics on search traffic as well as average rank of your content in search results.
The latest version of SassyStudio ended up being a lot more work than I had anticipated, but now that
it is done I'm extremely excited about what is coming up next for the project. For the next few releases
I will be focuessing primarily on intellisense
and expanding on what was added in v0.6.
Intellisense falls into three categories in Visual Studio:
Completion - The list of possible values
Quick Info - Information about a specific completion value
Signatures - Information about a method call (such as arguments and the order they appear)
In v0.6 I just shipped the initial support for completion which adds completion support for
keywords, variables, functions, and mixins. In future releases I will continue to expand the
scope of completions that are supported, but the core of what SCSS offers should have decent completion
support at this time. Quick Info and Signatures will be coming, but
likely not for a few releases.
Now, lets lay out what you can expect to see in the next few releases.
v0.7 - CSS Intellisense Released
Ultimately, v0.6 took so long because I ended up not being able to extend the current CSS editor and
had to recreate it on my own and that means I'll end up having to add the CSS intellisense on my own
as well. However, I can use the same source information that the regular CSS editor uses since it's
all stored in some XML files on the file system.
Since I don't have to compile a list of all CSS properties and elements and should be able to use
the schema files already included in Visual Studio, I'm cautiosly optimistic that v0.7 may be able
to be released before the end of the month.
v0.8 - SCSS Intellisense Released
Once we have support for basic CSS intellisense, I will be able to introduce intellisense into SCSS
specific contexts like nested properties. For instance, when we have some SCSS code like
.panel { font: { family: Helvetica, Arial, sans-serif; } }, we can limit completion values in the
font property block to the font- namespace like family, weight, etc.
As of right now, I'm not sure how difficult this would be, but I am thinking it should be simple and
we can expect that v0.8 will quickly follow v0.7.
v0.9 - Classic SASS support
By the time that v0.9 rolls around, I am hoping that I will have definitively determined how to easily
add support for .sass files for those who are still using them. Now, SASS and SCSS are so similar that
(as far as I am aware of right now), I should be able to just have my new tokenizer emit fake curly brace
tokens when the indentation level changes. If not, then I will just end up having to split the tokenizer
into two and share what I can, but the unique parts should be pretty small and thus I am again
cautiously optimistic that this should be a fairly simple and quick release.
v1.0 - Advanced Function Intellisense
For the 1.0 release I want to finally get the intellisense around functions to be on par with what you
see in other first class languages in Visual Studio. For 1.0 I will add support for viewing the function "signature"
so that you can see the arguments that the function is expecting for both system functiona and custom functions.
With this will also come general completion support for "named arguments" when calling a function (i.e. rgb($r: 255, $g: 255, $b: 255))
and likely some warnings if your function call is invalid.
Infinity and beyond
That gives you an overview of what to expect out of the next few releases, but beyond that is somewhat in
flux at this point. There's so much more to do with intellisense in addition to what I have laid out here
but they are much more complex (i.e. type inference on variables) that I felt that what I laid out in the
roadmap will be much more beneficial to the user.
If you have any feedback on what you would like to see in SassyStudio, feel free to leave a comment here
or enter it as an issue on GitHub.
