Cloud App has this neat feature wherein it automatically uploads new screenshots as they are added to the Desktop. Any ideas how this is done?
You can do similar things yourself without much in the way of programming. In OSX, you can configure "Folder Actions" to run a script, for example, when a new item appears in a folder, including the Desktop. You can then use the script to do whatever you want with the new files.
This article at TUAW includes an example of uploading files to a web server when they hit a particular folder.
So, basically, the answer is "Folder Actions", or "something's keeping an eye on the folder and sending notifications", at some level. Whether Cloud App uses Folder Actions or watches the folder itself at a lower level, using FSEvents/NSWorkspace, or the kqueue mechanisms (for which there's a nice wrapper class called UKKQueue, if I remember correctly -- don't know how current my knowledge is on that one though!) is another matter...
You could implement this at several different levels, depending on the outcome you want, how you want to design whatever it is you're actually doing, and even what kind of filesystem you're targeting. Fundamentally, in Cocoa/Objective C, I think you probably want to start looking at FSEvents.
Once you've got notifications of the file changes, I'd probably use something like ConnectionKit to do the uploading -- any library at all, really, that means you don't have to bother with the sockets level yourself -- but again, there's a lot of different ways.
Depends, really, what level you're looking to solve the problem at, and whether you want to build something for other people or get something working for yourself. If I just wanted to bash something together for myself, I could probably have something cobbled together using Coda's Transmit app, and Folder Actions, or maybe Hazel, and a minimal bit of Applescript, in a half-hour at most, that would do the job well enough for me...
I am not sure what you are asking for exactly. If you are asking for a way to take a screenshot programmatically in MacOSX, I suggest you have a look at the "screencapture" command (in the terminal, type "man screencapture" for doc).
If you want to do it the "hard" way, you should look at this.
Related
I wonder if it is possible to disable webpack folder in inspect, so users cant see my source code?
And if it's not possible, can users change it and run it?
Most commonly such a structured view is available only in development environment.
When the code is shipped to production environment it's normally minimized & bundled into one or several files which already makes it quite hard to read.
If you want to "hide" it from the user even further, you can use code obfuscation tools (you will likely need to pay for them) or move sensitive parts of your code to serverland.
Generally speaking, the only bulletproof way to hide the code from your users is never ship it to their browsers.
Whether the code is obfuscated or not, the user is alway able to change it & run. Obfuscation just makes it significantly more difficult.
There is a solution, you can try this in the "vue.config.js"
module.exports = {
productionSourceMap: true,
}
This option will tell Webpack to exclude the source code. Could be a solution for you.
Cheers
having the same issue here.
The Original Source files are NOT even close to the Server its running on and i tried multiple, independent Pcs now and everytime it showns me the full original source code in the Source list in chrome.
I dont really mind "showing" the source code but what annoys me is that this way people can literally steal the source and built the exact software on their own and it exposed stuff about my pc like directory of stuff, my full name (due to windows username), etc.
I would like to use MapKit (on osx) to display custom map tiles from a .mbtiles (sqlite) database of the sort exported from TileMill.
MBXMapKit looks great, and is almost what I'm looking for. I could see how, with very little modification, MBXMapKit could be tweaked to point to a local .mbtiles database file.
Is there any way to use the MBXMapKit framework to accomplish this without tweaking? I did read the docs, and couldn't find a straightforward answer. I did find a private method on MBXOfflineMapDatabase called -initWithContentsOfFile: which sounds promising and looks like it does what I need -- is there anything to watch out for if I expose and use that method?
Alternate option is to subclass MKTileOverlay and use -loadTileAtPath:result:, which is easy to do, but also requires managing the connection to the sqlite file etc.
Have a look at this for the latest on MBTiles support:
https://github.com/mapbox/mbxmapkit/issues/3
It'll be coming probably in the next release. This should be distinct and separate from both the normal performance cache (NSURLCache) as well as the (also SQLite-backed) offline databases, which are meant for individual tile downloads being placed into a cache one-by-one.
It took me quite some time to work this out, but here is the link that got me on the right path.
https://github.com/mapbox/mbxmapkit/pull/110/commits/8b9fbf3fd56ae804a38c737305f128fd43a8225d
For some reason the method _mbtilesOverlay = [[MBXMBTilesOverlay alloc] initWithMBTilesURL:mbtilesURL]; can not be used on the latest version of MBXMapKit. I just replaced the .m and .h files with the files in the link, and used MBXViewController.m as a guide to get the map view to show the tile overlay.
I'm writing an OS X launch agent (which watches, as it happens, for FSEvents);
it therefore has no UI and is not started from a bundle – it's just a program.
The relevant documentation and sample
code
illustrates persisting FS event IDs between invocations, and does so using
NSUserDefaults. This is clear the Right Thing To Do(TM).
The documentation for NSUserDefaults in the
Preferences and Settings Programming Guide
would appear to be the appropriate thing to read.
This shows only the Application and Global domains as being persistent, but (fairly
obviously) only the Application domain is writable for an application. However
the preferences in the application domain are keyed on the
ApplicationBundleIdentifier, which a launch agent won't have. So I'm at a loss
how such an agent should persist state.
All I can think of is that the Label in the launchd job can act as the
ApplicationBundleIdentifier – it at least has the correct form. But I can't see any
hint that that's correct, in the documentation.
The obvious (unix-normal) thing to do would be to write to a dot-file
in $HOME, but that's presumably not the Cocoa Way. Google searches
on 'osx daemon preferences', and the like, don't show up anything useful,
or else my google-fu is sadly lacking today. Googling for 'set application
bundle identifier' doesn't turn up anything likely, either.
NSUserDefaults:persistentDomainForName looks like it should be relevant,
but I can't work out its intentions from its method documentation.
I've found one question here which seems relevant, but while it's tantalisingly close, it doesn't say where the daemon gets its identifier from.
I've limited experience with Objective-C and Cocoa, which means that by
now I rather suspect I'm barking up the wrong tree, but don't really know where
to look next.
You can (and imo should) have an Info.plist even in a single-file executable.(see http://www.red-sweater.com/blog/2083/the-power-of-plist)
However, NSUserDefaults is a little more questionable. Conceptually, it's intended for user settings, rather than internal state. However, there's no real reason it wouldn't be suited to this, so I'd probably go ahead and do so.
this is my first post, and it covers something which I've been trying to get working on and off for about a year now.
Essentially it boils down to the following: I have a copy of newlib which I'm trying to get working on an LPC2388 (an ARM7TDMI from NXP). This is on a linux box using arm-elf-gcc
The question I have is that I've been looking at a lot of the tutorials talking about porting newlib, and they all talk about the stubs (like exit, open, read/write, sbrk), and I have a pretty good idea of how to implement all of these functions. But where should I put them?
I have the newlib distribution from sources.redhat.com/pub/newlib/newlib-1.18.0.tar.gz and after poking around I found "syscalls.c" (in newlib-1.18.0/newlib/libc/sys/arm) which contains all of the stubs which I have to update, but they're all filled in with rather finished looking code (which does NOT seem to work without the crt0.S, which itself does not work with my chip).
Should I just be wiping out those functions myself, and re-writing them? Or should I write them somewhere else. Should I make a whole new folder in newlib/libc/sys with the name of my "architecture" and change the target to match?
I'm also curious if there's proper etiquette on distribution of something like this after releasing it as an open source project. I currently have a script which downloads binutils, arm-elf-gcc, newlib, and gdb, and compiles them. If I am modifying files which are in the newlib directory, should I hand a patch which my script auto-applies? Or should I add the modified newlib to the repository?
Thanks for bothering to read! Following this is a more detailed breakdown of what I'm doing.
For those who want/need more info about my setup:
I'm building a ARM videogame console based loosely on the Uzebox project ( http://belogic.com/uzebox/ ).
I've been doing all sorts of things pulling from a lot of different resources as I try and figure it out. You can read about the start of my adventures here (sparkfun forums, no one responds as I figure it out on my own): forum.sparkfun.com/viewtopic.php?f=11&t=22072
I followed all of this by reading through the Stackoverflow questions about porting newlib and saw a few of the different tutorials (like wiki.osdev.org/Porting_Newlib ) but they also suffer from telling me to implements stubs without mentioning where, who, what, when, or how!
But where should I put them?
You can put them where you like, so long as they exist in the final link. You might incorporate them in the libc library itself, or you might keep that generic, and have the syscalls as a separate target specific object file or library.
You may need to create your own target specific crt0.s and assemble and link it for your target.
A good tutorial by Miro Samek of Quantum Leaps on getting GNU/ARM development up and running is available here. The examples are based on an Atmel AT91 part so you will need to know a little about your NXP device to adapt the start-up code.
A ready made Newlib porting layer for LPC2xxx was available here, but the links ot teh files appear to be broken. The same porting layer is used in Martin Thomas' WinARM project. This is a Windows port of GNU ARM GCC, but the examples included in it are target specific not host specific.
You should only need to modify the porting layer on Newlib, and since it is target and application specific, you need not (in fact probably should not) submit your code to the project.
When I was using newlib that is exactly what I did, blew away crt0.s, syscalls.c and libcfunc.c. My personal preference was to link in the replacement for crt0.s and syscalls.c (rolled the few functions in libcfunc into the syscalls.c replacement) based on the embedded application.
I never had an interest in pushing any of that work back into the distro, so cannot help you there.
You are on the right path though, crt0.S and syscalls.c are where you want to work to customize for your target. Personally I was interested in a C library (and printf) and would primarily neuter all of the functions to return 0 or 1 or whatever it took to get the function to just work and not get in the way of linking, periodically making the file I/O functions operate on linked in data in rom/ram. Basically without replacing or modifying any other files in newlib I had a fair amount of success, so you are on the right path.
About 2 months ago I overtook building proccess in current company. Even though I don't have much knowledge of it, I was the only with enough time, so I didn't have much choice.
Situation is not that good, and I would like to do following:
Labeling files in SourceSafe with version (example ProjectName PV 1.2)
GetFiles from SourceSafe to specific directory
Build vb6/c++/c# projects(yes, there are all kinds of them)
Build InstallShield setups
This is for now partly done using batch scripts(one for labeling and getting, one for building, etc..). So when building start I pretty much have babysit it.
Good part of this code could be reused.
Any recommendations on how to do it better? One big problem is whole bunch of dependencies between projects. Also labeling has to increment version and if necessary change PV to EV.
I would like to minimize user interaction as much as possible. One click on one build script(Spolsky is god) and all is done, no need to increment version, to set where to get files and similar stuff.
Is the batch scripting best way to go? Should I do some functionality with msbuild. Are there any other options?
Specific code is not need, for now I just need a way how to improve it, even though it wouldn't hurt.
Tnx,
Marko
Since you already have a build system (even though some of it currently "manual"), whatever you do, don't start over from scratch.
(1) Make sure you have a test machine (or Virtual Machine) on which to work. Thus you can make changes and improvements without having to worry about breaking anything.
(2) Put all of your build scripts and tools in version control, not just the source code. Then as you make changes, see if they work. If they do, then save them to version control. If they don't, then roll them back.
(3) Choose one area to work on at a time. Don't try to do everything at once. Going from a lot of manual work to "one-click" will take time no matter what build system you're working with.
Sounds like you want a continuous integration solution, like CC.Net. It has configuration options to do all the things you want and a great community to answer questions.
Also, batch scripting is probably not a good option. Sophisticated build and integration tools will let you feed parameters into the build and create different builds for different environments (test, production, etc.). Batch scripting will involve a lot of hand-coding and glue.